Database stores datetimes naive-UTC, but the dashboards and emails were
showing UTC strings to users in EST/EDT — making 9pm Toronto look like 1am
the next day. Adds a single helper module + auto-detection on install.
Core changes (fusion_plating):
- New fp_tz.py helper: fp_user_tz, fp_format, fp_isoformat_utc, fp_time_ago
Resolves user.tz → company.x_fc_default_tz → UTC.
- res.company.x_fc_default_tz Selection (full pytz IANA list)
- res.config.settings exposes the company tz under a new "Regional
Settings" block in Settings > Fusion Plating
- post_init_hook auto-populates the tz on first install: tries admin
user → server /etc/timezone → America/Toronto fallback
- fp_process_node._to_dict now sends create_date/write_date as ISO with
explicit +00:00 marker so JS new Date() parses it as UTC and the
recipe tree editor's "time ago" math works correctly
Shop-floor controllers:
- shopfloor_controller.py: every fields.Datetime.to_string() and naive
.strftime() swapped for fp_format(env, ...) — due_at, bake times,
last_log_date, gates, server_time all now in user's tz
- _time_ago() removed; replaced with fp_time_ago helper which compares
tz-aware datetimes (the local one was naive-vs-naive and could be
off by hours)
- manager_controller.py date_planned: str(...)[:10] slice replaced
with fp_format MM/DD in user's tz
Notifications + reports:
- mail_template_data.xml: 5 .strftime() calls in body_html → babel
format_datetime / format_date with tz=(user.tz or company tz)
- report_fp_job_traveller.xml: rec.received_date (Datetime) gets
t-options="{'widget':'datetime'}" so Odoo's QWeb renders in user tz
Settings view layout:
- fusion_plating now owns the Settings page "Fusion Plating" app shell
- fusion_plating_certificates xpaths into it instead of redefining
(prevents app-name collision)
Verified on odoo-entech (LXC 111): post_init_hook detects
America/Toronto from /etc/timezone, MO date_start 2026-04-17 05:28 UTC
correctly displays as 2026-04-17 01:28 EDT.
Module versions bumped: fusion_plating 19.0.3.0.0,
fusion_plating_shopfloor 19.0.9.0.0, plus certificates / notifications /
reports → 19.0.3.0.0.
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).