Files
Odoo-Modules/fusion_plating/fusion_plating_jobs
gsinghpal 32d48ea44d feat(jobs): step sequences are 1, 2, 3, ... not 10, 20, 30, ...
User feedback: operators kept asking why their work order said "Step 10"
for the first row. The 10-spacing was originally there to allow midpoint
inserts (insert sequence 15 between 10 and 20 without renumbering).
Tradeoff is operator confusion, and recipe authors rarely insert in the
middle anyway. Switching to 1-based contiguous sequences.

Files changed (every step-sequence allocation in the codebase):

fusion_plating_jobs/models/fp_job.py
  _generate_steps_from_recipe — seq_counter starts at 1, increments by 1.
  This is the path that builds fp.job.step records, so new jobs now show
  Step 1, 2, 3, ... in the work order.

fusion_plating_bridge_mrp/models/mrp_production.py
  Same change for the legacy MRP bridge so customers still on
  mrp.production also get 1-based numbering.

fusion_plating/controllers/recipe_controller.py
  - create_node: max_seq + 1
  - reorder_nodes: idx + 1
  - swap renumber: i (was i * 10)
  - paste-import renumber: i (was i * 10)
  - move_node: max_seq + 1
  - _copy_subtree (recipe duplicate/import): i (was i * 10)

fusion_plating/controllers/simple_recipe_controller.py
  - _sequence_for_position rewritten — always renumbers siblings to
    keep them contiguous. Returns pos + 1 for the inserted node.
    Old code used midpoint-with-fallback-to-renumber (10/20/30 spacing).
  - step_reorder: i (was i * 10)
  - library_input_add + step_add_input: existing_max + 1

What this DOESN'T do
  Existing fp.job.step records keep their old sequences (10, 20, ...).
  Re-confirm the SO to spawn a fresh job if you want the clean 1-based
  numbering on a current test job. No data migration — we're in dev
  and the user explicitly said test data is disposable.

What this DOES do
  Every NEW job created from this commit forward shows Step 1, 2, 3, ...
  Every NEW recipe step inserted via the simple editor / tree editor
  also gets sequence 1, 2, 3, ...

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 22:58:21 -04:00
..
2026-04-26 10:46:44 -04:00
2026-04-27 00:11:18 -04:00
2026-04-26 15:05:17 -04:00
2026-04-29 03:35:33 -04:00
2026-04-28 19:39:37 -04:00
2026-04-30 00:21:08 -04:00
2026-04-28 19:39:37 -04:00

fusion_plating_jobs

Native plating job bridge — wires fp.job and fp.job.step (defined in fusion_plating core, Phase 1 of the migration spec dated 2026-04-25) into the rest of the Fusion Plating module family: configurator, portal, logistics, quality, certificates, batches, KPI, notifications, reports.

Coexists with fusion_plating_bridge_mrp during the migration period. The x_fc_use_native_jobs settings flag (default: False) toggles the behaviour. When False, SO confirm continues to create mrp.production records through bridge_mrp. When True, SO confirm creates fp.job records here.

See docs/superpowers/specs/2026-04-25-fp-native-job-model-design.md for full design rationale and §6 of the implementation plan for phase breakdown.

Phase 6 — deferred items

Phase 6 originally scoped the full operator UI rewrite. With Tailscale SSH to entech currently unavailable we cannot live-test OWL/JS in the browser, so Phase 6 ships a lean version: the data-layer endpoints land now, the rendering UI lands later.

Deferred to post-cutover hardening:

  • Plant Overview kanban over fp.job.step — replaces fusion_plating_shopfloor's mrp.workorder kanban.
  • Tablet Station UI rewrite over fp.job / fp.job.step.
  • Manager Dashboard rewrite.
  • Process Tree OWL component — currently a stub: /fp/jobs/process_tree returns the serialized recipe tree as JSON, but the OWL component to render it is not built.

Rationale: these are large OWL/JS components that need live in-browser verification on entech. Under the migration's parallel-coexistence strategy, operators continue using the existing shopfloor UI (bound to mrp.workorder) until cutover. After cutover, the operator UI rewrite becomes its own focused project — the data layer (fp.job, fp.job.step, time logs, timestamps) is fully in place from Phase 15.

Phase 6 — what shipped

  • /fp/job/<id> — scan-redirect controller. The fp.job sticker QR encodes this URL. Routes managers to the fp.job form; routes operators to the same form for now (will swap to the process tree client action once the OWL component lands).
  • /fp/jobs/process_tree — JSON-RPC endpoint that returns the recipe tree for a job, with each node tagged by its matching fp.job.step state, ready for an OWL component to consume.