End-to-end workflow tightening + the team / skills system. Three
phases bundled because they share the same touchpoints (button_start /
button_finish / Manager Desk dropdown).
PHASE 1 — In-Odoo notifications + timer audit
=============================================
Workers now get a bell-icon notification (Odoo Discuss inbox) the
moment a manager assigns them a WO. No email — operators check Discuss
between jobs, and the customer-facing notification dispatcher stays
out of the worker loop.
- mrp.workorder.write() override fires message_notify(message_type=
'user_notification') only when x_fc_assigned_user_id transitions to
a non-empty value (clearing or no-op writes don't ping)
- 4 new fields on the WO header surface what was previously buried in
time_ids: x_fc_started_by_user_id, x_fc_started_at,
x_fc_finished_by_user_id, x_fc_finished_at
- button_start stamps started_* once (subsequent pause/resume cycles
preserve the original); button_finish stamps finished_* every time
the WO closes
- New "Timer Audit" group on the WO form (Time & Cost tab)
PHASE 2 — Presence-aware Manager Desk
=====================================
Manager Desk now knows who's clocked in. Works with vanilla
hr_attendance and fusion_clock — both expose hr.attendance with an
open record while the operator is on shift.
- bridge_mrp depends on hr_attendance
- hr.employee.x_fc_is_clocked_in computed field (batched query — one
DB hit for the whole employee set, not N+1)
- hr.employee._fp_clocked_in_user_ids() classmethod for the dashboard
- manager_controller sends operators with is_clocked_in / role_ids /
lead_hand_role_ids per worker, plus presence dict {clocked_in: N,
total: M}; each WO carries role_id/role_name so the dropdown can
match qualified operators
Manager Desk OWL:
- Header gets a "Present 7 / 12" pill chip; tap to toggle hideOffShift
(off-shift hidden when active, accent colour when filter is on)
- New operatorsForWO(wo) helper sorts dropdown options into 4 buckets:
qualified+clocked-in → lead-hand+clocked-in → clocked-in untrained
(training mode) → off-shift (greyed; only shown when hideOffShift
is false). Each option carries a ●/○ dot prefix and a soft suffix.
PHASE 3 — Skills, lead-hand-per-role, auto-promotion
====================================================
The team grows organically: managers assign training tasks, operators
finish them, the system auto-promotes after N successful runs.
- fp.work.role.mastery_required (integer, default reads from the
company-level Default Mastery Threshold). Each role can override —
masking might need 1 success, electroless nickel 5.
- res.company.x_fc_default_mastery_threshold + res.config.settings
exposure under "Workforce Settings" in the Fusion Plating settings
block (default 3)
- hr.employee.x_fc_lead_hand_role_ids m2m, separate from
x_fc_work_role_ids — Sarah can be a lead hand for masking + racking
even if those aren't her primary roles. Manager-only group access.
- New fp.operator.proficiency model (one row per employee+role) with
completed_count, first/last_completed_at, promoted, promoted_at,
progress_label compute. SQL-unique on (employee, role).
- mrp.workorder.button_finish increments the (employee, role)
counter, then if count >= role.mastery_required AND not promoted,
adds the role to x_fc_work_role_ids and posts a "🎉 Promoted"
chatter line on the employee record. Wrapped in try/except so a
tracker glitch never blocks production.
- Promotion uses the WO's assigned_user_id, NOT env.user — credit
goes to the operator who was supposed to do it, even if a manager
finished on their behalf.
Employee form gets a "Shop Roles" tab (supervisor+):
- "Tasks This Operator Can Do" m2m
- "Lead Hand For" m2m (manager-only)
- Read-only Task Proficiency list with progress / promotion badges
Verified on odoo-entech: all fields land, default threshold = 3,
asset bundle regenerated as 9f38f05.
Module bumps: fusion_plating 19.0.4.0.0,
fusion_plating_bridge_mrp 19.0.4.0.0,
fusion_plating_shopfloor 19.0.11.0.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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 startwindow_hours— customer specbake_required_by— computed deadlinestate—awaiting_bake -> bake_in_progress -> baked, withmissed_window/scrappedexit paths- A 5-minute cron that flips records past their deadline to
missed_windowautomatically - 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/scanPOST /fp/shopfloor/log_chemistryPOST /fp/shopfloor/start_bakePOST /fp/shopfloor/end_bakePOST /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