Files
Odoo-Modules/fusion_plating/fusion_plating_shopfloor
gsinghpal 9794a98de9 feat(jobs): Sub 13 sequential step enforcement + Sub 12e v3 wizard
Two coherent feature drops shipping together because their fp_job_step
edits overlap. Both target operator workflow correctness.

## Sub 13 — Sequential step enforcement (recipe + per-step)

Background:
  Investigation on WH/JOB/00339 showed operators starting Incoming
  Inspection while Contract Review was still in_progress. Audit:
  98.7% of recipe operations system-wide had requires_predecessor_done
  = false (the legacy per-step opt-in defaults off, recipe authors
  rarely tick the box).

Architecture:
  Recipe-level toggle + per-step opt-out (Option A from /investigate).
  * fusion.plating.process.node.enforce_sequential — Boolean on the
    recipe root. Default True. When True, every operation under this
    recipe waits for earlier-sequence steps to finish before it can
    start.
  * fusion.plating.process.node.parallel_start — Boolean on operation
    nodes. When True, this step bypasses the sequential gate (e.g.
    paperwork or QA review that runs alongside production).
  * Mirrored on fp.step.template (parallel_start) so library steps
    carry the flag into snapshots.
  * fp.job.enforce_sequential — related from recipe_id. Snapshotted
    at job creation so a recipe author flipping the recipe's flag
    AFTER job generation does NOT change behaviour mid-run.
  * fp.job.step.parallel_start — related from recipe_node_id.
  * Decision matrix (encapsulated in
    fp.job.step._fp_should_block_predecessors):
        recipe.enforce_sequential | step.parallel_start | step.req_pred_done | block?
        --------------------------|---------------------|--------------------|------
                 True             |       False         |        any         |  YES
                 True             |       True          |        any         |   no
                 False            |        any          |       True         |  YES
                 False            |        any          |       False        |   no
  * Manager bypass via context fp_skip_predecessor_check=True (existing).

Runtime gates:
  * fp.job.step.button_start — calls _fp_should_block_predecessors;
    raises UserError naming the blocking earlier step(s).
  * fp.job.step.can_start — computed Boolean for view-side disable.
  * Move wizard predecessor check
    (fusion_plating_shopfloor/controllers/move_controller.py) — uses
    the same helper so tablet + backend behave identically.

UI surface:
  * Recipe form (fp_process_node_views.xml) — enforce_sequential
    toggle on recipe root, parallel_start checkbox on operations.
  * Step template form — parallel_start checkbox.
  * Simple Recipe Editor (inline library form) — Parallel Start
    checkbox + legacy flag demoted with muted styling + supervisor
    group gate.
  * Recipe Tree Editor (properties panel) — both flags exposed,
    only-show on the right node_type.
  * Controllers updated to allowlist + payload the new fields.

Migration:
  fusion_plating/migrations/19.0.18.12.0/post-migrate.py — sets
  enforce_sequential = TRUE on every existing recipe-root node.
  Idempotent. User confirmed dev-stage data, so retroactive flip
  is safe (no production jobs to disrupt).

Tests:
  TestSequentialEnforcement (10 tests) covering:
    * sequential mode blocks out-of-order start
    * first step always startable
    * predecessor finish/skip unlocks next
    * parallel_start opts out of gate
    * free-flow mode bypasses gate
    * legacy requires_predecessor_done still honoured in free-flow
    * manager bypass via context
    * can_start compute reflects state correctly
    * library template parallel_start snapshots into recipe-node

## Sub 12e — Record Inputs Wizard v3 (card layout, dark-mode aware)

Background:
  v2 wizard was a 17-column wide editable table. Operators got lost
  finding which value column applied to their row's type, horizontal
  scroll required on tablets, composite types crammed into one row.

New layout:
  * Each measurement renders as a stacked card (CSS Grid + display
    transformation on the existing list widget — preserves inline
    editing, no JS rewrite).
  * Card header: prompt name (large, bold) + type/unit pills.
  * Card body: ONLY the value widget for this row's type
    (number / boolean / date / text / photo / multi-point / panel).
  * Composite types (multi-point thickness 5x reading + avg, bath
    panel 4 fields) get inline sub-grid inside the card.
  * Empty state ("no measurement prompts") with friendly CTA.

Dark mode:
  * SCSS branches at compile time on $o-webclient-color-scheme
    (per fusion-plating/CLAUDE.md note).
  * Tokens: 7 surface colours + 4 ink levels with light/dark hex
    pairs, all behind var(--fp-*) custom properties for per-deploy
    override.
  * Registered in BOTH web.assets_backend AND web.assets_web_dark
    so each bundle compiles its own palette.

Tablet polish:
  @media (max-width: 900px) — collapse meta below prompt + bump
  numeric input min-height to 56px.

Defensive:
  * v2 view kept in the XML file (instant rollback by changing one
    view_id ref).
  * `:has(.o_invisible_modifier)` rule drops empty cells out of the
    grid so Odoo's invisible="..." doesn't punch holes in layout.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 21:24:12 -04:00
..
2026-04-16 20:53:53 -04:00
2026-04-27 00:11:18 -04:00
2026-04-16 20:53:53 -04:00
2026-04-28 19:39:37 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00

Fusion Plating — Shop Floor

Tablet / operator ergonomics layer for the fusion_plating core.

Part of the Fusion Plating product family by Nexa Systems Inc. Copyright (c) 2026 Nexa Systems Inc. All rights reserved. Licensed under OPL-1 (Odoo Proprietary License v1.0).

What this module adds

Feature Model
Tablet station registration fusion.plating.shopfloor.station
Bake oven master + chart recorder ref fusion.plating.bake.oven
Hydrogen embrittlement bake-window enforcer fusion.plating.bake.window
First-piece inspection gate fusion.plating.first.piece.gate
Operator next-up queue (transient) fusion.plating.operator.queue

Bake-window enforcer

When a high-strength-steel part exits the plating tank, a clock starts. Customer specification dictates the window (typically 1-4 hours) inside which the relief bake must begin. Missing the window requires scrap or rework — there is no retroactive fix.

The module models this as a first-class entity with:

  • plate_exit_time — clock start
  • window_hours — customer spec
  • bake_required_by — computed deadline
  • stateawaiting_bake -> bake_in_progress -> baked, with missed_window / scrapped exit paths
  • A 5-minute cron that flips records past their deadline to missed_window automatically
  • A kanban board grouped by state with theme-aware status colours

Tablet client

A backend OWL component (Odoo 19 conventions) registered as the fp_shopfloor_tablet client action. It hosts:

  • QR scan input (wedge scanner or on-screen keyboard friendly)
  • Live tank / bath / job preview cards
  • One-tap Start Bake / End Bake buttons
  • Live operator next-up queue

JSON-RPC endpoints (Odoo 19 type='jsonrpc'):

  • POST /fp/shopfloor/scan
  • POST /fp/shopfloor/log_chemistry
  • POST /fp/shopfloor/start_bake
  • POST /fp/shopfloor/end_bake
  • POST /fp/shopfloor/queue

QR code conventions

Prefix Resolves to
FP-TANK:<code> fusion.plating.tank
FP-BATH:<name> fusion.plating.bath
FP-STATION:<code> fusion.plating.shopfloor.station
FP-JOB:<name> fusion.plating.bake.window
FP-OVEN:<code> fusion.plating.bake.oven

Security

Reuses the four core Fusion Plating groups (operator, supervisor, manager, admin) defined in fusion_plating. No new groups, no new privilege block. ACLs are graded operator (read/write logs), supervisor (create), manager (full).

Theme

All styling is theme-aware: CSS custom properties + color-mix() against Bootstrap / Odoo tokens. No hex codes, no media queries — works in light and dark mode out of the box.

Install / update

docker exec odoo-dev-app odoo -d fusion-dev -u fusion_plating_shopfloor --stop-after-init