Files

gsinghpal 0d12902ee7 feat(plating): in-Odoo notifications, timer audit, presence-aware Manager Desk, auto-promotion

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>

2026-04-18 22:05:32 -04:00

controllers

folder rename

2026-04-16 20:53:53 -04:00

data

folder rename

2026-04-16 20:53:53 -04:00

models

feat(plating): in-Odoo notifications, timer audit, presence-aware Manager Desk, auto-promotion

2026-04-18 22:05:32 -04:00

security

feat(fusion_plating): Tier 2 (quality + audit) and Tier 3 (business) features

2026-04-16 23:55:22 -04:00

static

folder rename

2026-04-16 20:53:53 -04:00

views

feat(plating): in-Odoo notifications, timer audit, presence-aware Manager Desk, auto-promotion

2026-04-18 22:05:32 -04:00

__init__.py

feat(plating): comprehensive timezone fix across dashboards/PDFs/emails

2026-04-18 21:03:02 -04:00

__manifest__.py

feat(plating): in-Odoo notifications, timer audit, presence-aware Manager Desk, auto-promotion

2026-04-18 22:05:32 -04:00

README.md

folder rename

2026-04-16 20:53:53 -04:00

README.md

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.

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

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.
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 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).