Files

gsinghpal f4e1f9d218 refactor(plating-sec): extend ACL sweep to 13 missed modules

The Phase B plan (commit 8eb2c2de) listed 12 modules to sweep, but the
codebase has 13 more modules with ACL CSVs referencing the old role
group xmlids. Backward-compat (Phase A's implied_ids chains) keeps
these working today, but the old groups will be deleted after the
30-day rollback window — so the sweep must cover ALL modules with
plating-group ACL refs to avoid post-rollback breakage.

Sweeps: batch, bridge_documents, bridge_maintenance, bridge_mrp
(uninstalled but file present), bridge_quality (planned removal),
bridge_sign, compliance, culture (retired), kpi, logistics,
notifications, portal, reports.

Pattern matches the original sweep:
  group_fusion_plating_operator → group_fp_technician
  group_fusion_plating_supervisor → group_fp_shop_manager_v2
  group_fusion_plating_manager → group_fp_manager
  group_fusion_plating_admin → group_fp_owner
  group_fp_accounting → group_fp_manager
  group_fp_receiving → group_fp_shop_manager_v2
  group_fp_estimator → group_fp_sales_rep
  group_fp_shop_manager (legacy) → group_fp_manager
  cgp_officer → group_fp_quality_manager
  cgp_designated_official → group_fp_owner

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-24 01:18:52 -04:00

data

folder rename

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

models

folder rename

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

security

refactor(plating-sec): extend ACL sweep to 13 missed modules

2026-05-24 01:18:52 -04:00

views

folder rename

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

__init__.py

folder rename

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

__manifest__.py

refactor(plating-sec): extend ACL sweep to 13 missed modules

2026-05-24 01:18:52 -04:00

README.md

folder rename

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

README.md

Fusion Plating — Quality Bridge (EE)

Part of the Fusion Plating product family by Nexa Systems Inc.

One-way sync from Fusion Plating NCRs to Odoo Enterprise quality.alert records. Lets plating shops running Odoo EE keep using the Fusion Plating QMS (CE + EE compatible) while getting the benefit of EE's native quality dashboards on the same data.

Status

Item	Value
Odoo version	19.0
License	OPL-1
Auto-install	Yes — when `fusion_plating_quality` AND EE `quality` are both installed
Sync direction	One-way: NCR → quality.alert

How it works

Creating or updating a fusion.plating.ncr record triggers _sync_to_quality_alert() in models/fp_ncr.py.
The bridge builds a vals dict from the NCR and creates (or updates) the linked quality.alert record under a dedicated Plating Quality team.
The bridge is defensive: every field write is gated on the live quality.alert schema so a minor EE release that renames or drops a field does not break NCR saves.
If quality.alert is not available for any reason, the sync silently no-ops — NCRs continue to work normally in the base QMS module.

Field mapping

Fusion Plating NCR	Odoo EE quality.alert
`description` (first line)	`name` / `title`
`description` (full html)	`description` (if html) or stripped text
`containment`	`action_corrective` (if present)
`root_cause`	`action_preventive` (if present)
`severity`	`priority` (0/1/2/3 star)
`state`	`stage_id` (best-effort name match)
`customer_partner_id`	`partner_id`
`company_id`	`company_id`
—	`team_id` (always "Plating Quality")

Per-record controls

Each NCR gains three x_fc_* fields (visible under the Quality Alert Sync notebook page on the NCR form):

x_fc_auto_sync — toggle per-record sync; set to False to freeze the mirror on a specific NCR
x_fc_quality_alert_id — read-only pointer to the mirrored alert
x_fc_quality_alert_synced — read-only "has been synced at least once" flag

Manual sync

Use the Sync to Quality header button on the NCR form to push the latest values on demand. The mirrored alert's Quality Alert smart button jumps straight to the linked EE record.

What the bridge does NOT do

No write-back. Edits to the EE quality.alert record are not propagated back into Fusion Plating. NCR is the source of truth.
No CAPA mirroring. Fusion Plating CAPAs remain in fusion.plating.capa; they are not copied into quality.point or quality.check.
No historical backfill. Existing NCRs created before this module was installed are not synced automatically — run the Sync to Quality button manually on the ones you want mirrored.

Notes for deployment

If your EE release uses quality.team instead of quality.alert.team, edit data/quality_alert_team_data.xml to match and reinstall the module. No Python changes required.
The sync runs with sudo() so shop operators without direct write access to the EE quality module still produce mirrored alerts cleanly.