Files
Odoo-Modules/fusion_plating/fusion_plating
gsinghpal 6c4ff7751f feat(plating): comprehensive timezone fix across dashboards/PDFs/emails
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>
2026-04-18 21:03:02 -04:00
..
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00
2026-04-16 20:53:53 -04:00

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_oxide etc. 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, _cgp etc. 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

  1. Works on both Odoo Community and Enterprise. Never depends on quality, documents, sign, studio, or mrp_plm. EE-specific integrations live in separate fusion_plating_bridge_* modules.
  2. No client-specific strings in core. Configuration, not code.
  3. Regions are data, not code. Sewer limits, waste classes, reporting forms come from region packs.
  4. Processes are plug-ins. New process (copper, zinc, tin) = new fusion_plating_process_* module, core untouched.
  5. Dashboards are configured, not coded. Shops pick their own headline KPIs.
  6. 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 the x_fc_ prefix per the repo convention.

Developer notes

  • All models inheriting from mail.thread use the Odoo 19 chatter pattern.
  • Security follows the Odoo 19 res.groups.privilege pattern (module category → privilege → groups), not the legacy category_id-on-group pattern.
  • Sequence numbers use ir.sequence seeded in data/fp_sequence_data.xml.
  • SCSS uses color-mix() against CSS custom properties — never hardcodes hex values. See static/src/scss/fusion_plating.scss for the theming contract.
  • No group expand="0" in search views (Odoo 19 incompatibility).
  • No category_id or users field on res.groups (Odoo 19 incompatibility).