Replaces the generic Draft/Confirmed/In Progress/Done statusbar with
a shop-configurable list of plating-specific milestones. Bar advances
automatically as recipe steps complete; no manual button clicks.
What ships
==========
* New model: fp.job.workflow.state
Catalog of milestones (name, code, sequence, color, triggers).
Triggers can be:
- trigger_default_kinds: "receiving,inspect" matches by step.default_kind
- trigger_first_step_started: any wet/bake/mask/rack step started
- trigger_all_steps_done: every non-cancelled step in done/skipped
- block_when_quality_hold: held back while NCR/hold open
Plus per-recipe-node override (see below).
* Default 7-state seed (data/fp_workflow_state_data.xml):
Draft → Confirmed → Received → In Progress → Inspected → Shipped → Done
noupdate=1 so per-shop edits survive module upgrade.
* Recipe-side trigger field on fusion.plating.process.node:
triggers_workflow_state_id (Many2one, optional)
Wins over default_kind matching. Lets the recipe author pin a
specific step as a milestone trigger even when default_kind isn't
set or doesn't match. Exposed in the Recipe Tree Editor properties
panel (dropdown sourced from the catalog).
* fp.job.workflow_state_id (computed, stored)
Iterates the catalog in sequence order; lands at the highest passed
milestone. Recomputes on step state / kind / recipe_node / quality
hold changes. Replaces fp.job.state on the form's statusbar.
* Settings UI: Configuration > Workflow States
Standard list+form pages so admins can add / edit / deactivate
states. Manager-group write permission, supervisor read.
What this does NOT do
=====================
* Doesn't drop fp.job.state — that field still drives the internal
state machine (button_confirm, action_cancel, etc.). Only the
UI statusbar is reassigned.
* No migration for existing jobs — they auto-recompute on next read
because workflow_state_id is a stored compute with the right
api.depends. Existing WH/JOB/00342 will display its current
workflow state on next page load.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fusion Plating
Core module of the Fusion Plating product family. A configurable, multi-tenant capable ERP for plating and metal-finishing shops, built for Odoo 19 Community and Enterprise.
Copyright © 2026 Nexa Systems Inc. License: OPL-1 (Odoo Proprietary License v1.0)
What this module is
fusion_plating is the process-agnostic foundation that every plating or
metal-finishing shop needs, regardless of size, jurisdiction, process mix, or
industry. It provides:
- Facility — physical sites with their own tanks, operators, capabilities
- Process Type — extensible taxonomy (filled in by process packs)
- Work Center — lines and stations inside a facility
- Tank — physical vessel with QR code, state, bath history
- Bath — the chemistry currently in a tank, with its own lifecycle
- Bath Parameter — schema for chemistry readings
- Bath Log — daily/per-shift chemistry readings with pass/warn/fail rollup
- Security — Operator / Supervisor / Manager / Administrator roles
- Theme-aware UI — respects Odoo light/dark mode with zero duplication
What this module is not
This core intentionally ships with:
- No process chemistry — install
fusion_plating_process_en,_chrome,_anodize,_black_oxideetc. to get actual process types and their bath parameter schemas. - No regulatory data — install
fusion_plating_compliance_<region>to get jurisdiction-specific limits, forms, and reporting workflows. - No industry specialisations — install
fusion_plating_aerospace,_nuclear,_cgpetc. for industry-specific QMS overlays. - No client-specific strings — everything is data-driven.
Product family
| Module | Purpose | Status |
|---|---|---|
fusion_plating |
Core (this module) | MVP |
fusion_plating_quality |
QMS: NCR, CAPA, doc control, calibration, CoC | planned |
fusion_plating_compliance |
Generic compliance framework | planned |
fusion_plating_compliance_on |
Ontario regulatory pack | planned |
fusion_plating_compliance_tor |
Toronto Ch. 681 municipal pack | planned |
fusion_plating_safety |
SDS, WHMIS/TDG, JHSC, exposure | planned |
fusion_plating_shopfloor |
Tablet operator stations, QR scanning, bake-window enforcer | planned |
fusion_plating_portal |
Customer portal | planned |
fusion_plating_process_en |
Electroless nickel — low/mid/high phos | planned |
fusion_plating_process_chrome |
Chrome coating (hex & trivalent) | planned |
fusion_plating_process_anodize |
Aluminum anodizing (Type II, III) | planned |
fusion_plating_process_black_oxide |
Black oxidizing | planned |
fusion_plating_aerospace |
AS9100 + Nadcap AC7108 | planned |
fusion_plating_nuclear |
CSA N299, CNSC, NQA-1 | planned |
fusion_plating_cgp |
Controlled Goods Program | planned |
fusion_plating_logistics |
Pickup & delivery routing | planned |
fusion_plating_culture |
Values / fundamentals framework | planned |
fusion_plating_bridge_sign |
EE bridge: e-sign CoC acceptance | planned |
fusion_plating_bridge_documents |
EE bridge: Documents workspace | planned |
fusion_plating_bridge_quality |
EE bridge: native quality module |
planned |
Installation
# Development
docker exec odoo-dev-app odoo -d fusion-dev -u fusion_plating --stop-after-init
# Production — after rsync to target server
docker exec <odoo-container> odoo -d <db> -u fusion_plating --stop-after-init
No external Python dependencies. Depends only on standard Odoo 19 Community
base modules (base, mail, contacts, product, stock, sale_management,
purchase, hr, uom).
Design principles
- Works on both Odoo Community and Enterprise. Never depends on
quality,documents,sign,studio, ormrp_plm. EE-specific integrations live in separatefusion_plating_bridge_*modules. - No client-specific strings in core. Configuration, not code.
- Regions are data, not code. Sewer limits, waste classes, reporting forms come from region packs.
- Processes are plug-ins. New process (copper, zinc, tin) = new
fusion_plating_process_*module, core untouched. - Dashboards are configured, not coded. Shops pick their own headline KPIs.
- Theme-aware. Uses Odoo/Bootstrap CSS variables. One source of truth for colours; Odoo's theme engine decides light vs dark.
Security groups
| Group | Intended for |
|---|---|
| Operator | Shop-floor staff. Reads reference data, writes chemistry logs. |
| Supervisor | Line supervisors. Manages baths, schedules jobs, reviews logs. |
| Manager | Quality, EHS, plant manager, engineer. Full CRUD on configuration. |
| Administrator | Owner, system admin. All manager rights + system settings. |
Field naming convention
- New models use
fusion.plating.*namespace. - Fields on our own models use simple names (no prefix).
- Fields added to base Odoo models (
res.company,res.partner,product.template, etc.) use thex_fc_prefix per the repo convention.
Developer notes
- All models inheriting from
mail.threaduse the Odoo 19 chatter pattern. - Security follows the Odoo 19
res.groups.privilegepattern (module category → privilege → groups), not the legacycategory_id-on-group pattern. - Sequence numbers use
ir.sequenceseeded indata/fp_sequence_data.xml. - SCSS uses
color-mix()against CSS custom properties — never hardcodes hex values. Seestatic/src/scss/fusion_plating.scssfor the theming contract. - No
group expand="0"in search views (Odoo 19 incompatibility). - No
category_idorusersfield onres.groups(Odoo 19 incompatibility).