Odoo-Modules/fusion_plating/docs/superpowers/specs/2026-05-04-fp-step-kind-model.md

FP Step Kind — User-Extensible Model

Date: 2026-05-04 Status: design + implementation

Problem

default_kind on fp.step.template is a hardcoded Selection of 24 entries. Users can't add new kinds (e.g. "Shot Peen", "Passivation"). The same Selection list is duplicated on fusion.plating.process.node. Default-input seeding (DEFAULT_INPUTS_BY_KIND) is also locked in Python — adding a new kind would require a code change + module update.

Solution

Convert default_kind from Selection → Many2one('fp.step.kind'). Move the default-input templates from a Python dict into seeded data records on a new fp.step.kind.default.input child model. Users add new kinds through the standard Odoo CRUD form.

Models

fp.step.kind

Field	Type	Notes
code	Char, required, unique per company	Technical key (lowercase). Stable XML IDs use this.
name	Char, required, translated	UI label (e.g. "Cleaning")
sequence	Integer	Order in dropdown
active	Boolean default True	Archive instead of delete
icon	Selection (reuses 24-icon list from fp.process.node)	Optional
description	Html	Optional ops note
company_id	Many2one res.company	Multi-co support
default_input_ids	One2many → fp.step.kind.default.input	The seed list

fp.step.kind.default.input

Same shape as fp.step.template.input: name, input_type, target_unit, sequence, required, hint, selection_options. Plus kind_id parent FK.

Field changes

fp.step.template

• add kind_id = Many2one('fp.step.kind', ondelete='restrict', string='Step Kind') — user-facing input
• change existing default_kind from Selection(...) to default_kind = fields.Char(related='kind_id.code', store=True, readonly=True) — back-compat shim. Lets every legacy node.default_kind == 'cleaning' comparison keep working without touching 30+ sites. Stored=True so existing search domains (('default_kind', '=', 'foo')) still work.

fusion.plating.process.node

• Same: add kind_id, convert default_kind to related='kind_id.code' stored Char.

fp.job.workflow.state.trigger_default_kinds

• No change in Phase 1. Stays a Char of comma-separated codes. The codes still match kind_id.code after migration. Phase 2 deferred convert to m2m.

DEFAULT_INPUTS_BY_KIND

Removed from fp_step_template.py. Lives in seed data XML. action_seed_default_inputs reads tpl.kind_id.default_input_ids instead of the dict.

Migration 19.0.18.13.0/post-migrate.py

1. SQL-read existing default_kind text values from fp_step_template and fusion_plating_process_node BEFORE Odoo recomputes the related field.
2. Build map code → fp.step.kind.id from seeded records.
3. SQL UPDATE kind_id per row.
4. Trigger recompute of stored related default_kind (or leave — values are already there from step 1).
5. Log counts.

Why not drop default_kind entirely?

• Comma-CSV trigger_default_kinds on workflow state still searches it.
• 30+ comparison sites and existing search domains in views.
• Stored related Char keeps it a single source of truth (m2o-derived) without a churn-PR through every dependent.

View changes

• fp_step_template_views.xml — replace <field name="default_kind"/> with <field name="kind_id" options="{'no_create_edit': false, 'no_quick_create': false}"/>. Same for search filter and group_by="default_kind" → group_by="kind_id".
• fp_process_node_views.xml — same swap on the one occurrence.
• New fp_step_kind_views.xml — list/form/menu so admins can manage kinds. Form embeds default_input_ids as inline list.

Controller / JS changes

• simple_recipe_controller.py:
  • Add kind_id (id) and kind_name (label) to all step-payload responses.
  • Accept kind_id int on _save_recipe/template-create endpoints.
  • Keep returning default_kind (the code Char) for back-compat with deployed editor sessions until cache flushes.
• simple_recipe_editor.js:
  • Replace the <select> over selection options with a Many2one-style typeahead. Fetch list from new endpoint /fusion_plating/recipe/kinds returning [{id, code, name, icon}].
  • Submit kind_id (int) instead of default_kind (string).
• simple_recipe_editor.xml:
  • Replace <select t-model=".default_kind"> block with a <select t-model=".kind_id"> populated from fetched list, plus a "+ New kind…" link that opens a small inline form via /fusion_plating/recipe/kinds/create.

ACLs (ir.model.access.csv)

access_fp_step_kind_operator,fp.step.kind.operator,model_fp_step_kind,group_fusion_plating_operator,1,0,0,0
access_fp_step_kind_supervisor,fp.step.kind.supervisor,model_fp_step_kind,group_fusion_plating_supervisor,1,1,1,0
access_fp_step_kind_manager,fp.step.kind.manager,model_fp_step_kind,group_fusion_plating_manager,1,1,1,1
access_fp_step_kind_default_input_*  …  same triplet

Manifest

• Bump version to 19.0.18.13.0
• Add to data:
  • data/fp_step_kind_data.xml (BEFORE fp_step_template_data.xml since templates reference kinds)
  • views/fp_step_kind_views.xml

Out of scope (Phase 2)

• Convert trigger_default_kinds Char-CSV to m2m on fp.job.workflow.state
• Remove DEFAULT_INPUTS_BY_KIND dict from migration scripts (one-shot dev scripts — no harm leaving)
• Migrate stored default_kind Char to a non-stored related once all callers refactored

Test plan

1. odoo -d admin -u fusion_plating --stop-after-init (entech) — install + migration runs cleanly
2. UI smoke: open a step template, kind dropdown shows 24 seeded kinds, dropdown allows quick-create
3. Create new kind "Passivation" with 3 default inputs → save → return to step template → "Seed defaults" button populates the 3 inputs
4. Open recipe editor (simple): kind dropdown matches; existing recipes show correct kind label
5. Run a step that's wired through workflow-state trigger (e.g. completion of a receiving step → state changes to "On Floor") to confirm CSV-trigger backwards compat still works