Files

gsinghpal 269f9984ef feat(plating-views): Layer 3 — field/button gates per role

Phase D Task D5 of permissions overhaul. Adds explicit groups= to
form-level elements so non-matching roles don't even SEE the buttons
they can't use:

- SO Confirm button → group_fp_sales_manager (Sales Rep sees the SO
  in draft but no Confirm button — matches model-level gate from Phase G)
- SO pricing fields (price_unit/subtotal/total/untaxed/tax) →
  group_fp_sales_rep (Technician/Shop Manager don't see pricing if
  they navigate to an SO)
- Partner Account Hold tab → group_fp_manager (was the fold-in
  group_fp_accounting; the audit-finding-11 _administrator typo lives
  in res_partner.py and is Phase G's fix)
- CAPA Close + all state-transition buttons → group_fp_quality_manager;
  edit fields use readonly="not user_has_groups(...)" so Manager
  retains read+comment per spec section 2.C
- Audit Start/Findings/Close buttons → group_fp_quality_manager
- AVL Approve/Suspend/Reinstate/Remove → group_fp_quality_manager
  (model uses Suspend+Remove instead of spec's literal 'Disqualify';
  both surfaces gated, semantics match)
- Customer Spec edit fields → readonly for non-QM (Manager keeps
  read access per spec; only inputs lock)
- FAIR Approve/Reject buttons → group_fp_quality_manager (Submit-
  for-Review and Reset stay open to whoever created the FAIR)
- Certificate Issue button — Strategy B chosen: single button hidden
  when cert_type=nadcap_cert AND user is not QM. Cleaner than splitting
  into two buttons; no separate action_sign exists on fp.certificate
  (Issue is the sign+publish action). FAIR lives in its own model;
  fp.certificate only has nadcap_cert as a special type. The ir.rule
  from Phase C enforces model-level writes independently.
- CGP form buttons (7 view files: ai, controlled_good, psa,
  receipt_shipment, registration, security_incident, visitor) →
  group_fp_quality_manager on every action button

Defense in depth: ir.rules and ACLs (from Phases B + C) already
restrict model access. These view gates are the UI layer that
matches.

Concerns:
- Spec line 192 names 'sale.order view — x_fc_account_hold_override'
  but no such field exists in the codebase. Closest practical match
  was the partner-side Account Hold management tab, which already had
  a group= attribute. Re-gated there; no SO-side field to gate.
- AVL model has no action_disqualify per spec; uses suspend+remove.
  Both gated to QM.
- fp.certificate has no action_sign (only action_issue). FAIR's
  approve/reject covers the FAIR side; nadcap-cert Issue covers the
  cert side via Strategy B.

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

2026-05-24 01:45:39 -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): sweep all ACL CSVs to new role group xmlids

2026-05-24 01:14:02 -04:00

static/src/scss

folder rename

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

views

feat(plating-views): Layer 3 — field/button gates per role

2026-05-24 01:45:39 -04:00

__init__.py

folder rename

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

__manifest__.py

feat(plating-views): Layer 3 — field/button gates per role

2026-05-24 01:45:39 -04:00

README.md

folder rename

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

README.md

Fusion Plating — Controlled Goods Program (CGP)

Canadian Controlled Goods Program compliance pack for plating shops doing defence or ITAR-adjacent work. Part of the Fusion Plating product family by Nexa Systems Inc.

What it covers

The Controlled Goods Program (CGP) is administered by Public Services and Procurement Canada (PSPC) under the Defence Production Act. Every Canadian entity that examines, possesses, or transfers controlled goods must be registered, must appoint an Authorized Individual, must run Personnel Security Assessments on anyone with access, and must maintain visitor, movement, and incident logs. Non-compliance is a criminal offence.

This module layers the minimum record set to stay audit-ready on top of the Fusion Plating core.

Records

Model	Purpose
`fusion.plating.cgp.registration`	Company CGP registration with PSPC, 5-year renewal
`fusion.plating.cgp.authorized.individual`	AI appointment, training, state
`fusion.plating.cgp.psa`	Personnel Security Assessment (restricted)
`fusion.plating.cgp.visitor`	Visitor log with PSA / escort / approval
`fusion.plating.cgp.controlled.good`	Inventory of controlled goods handled
`fusion.plating.cgp.receipt.shipment`	Movement log with AI authorization
`fusion.plating.cgp.security.incident`	Security incidents, PSPC notification (restricted)
`fusion.plating.cgp.access.log`	Physical access log for controlled areas

It also extends hr.employee with CGP fields (x_fc_cgp_psa_id, x_fc_cgp_ai, etc.) and res.company with a link to the current CGP registration.

Security

CGP data is sensitive. This module introduces a new restricted group on top of the core fusion_plating.group_fusion_plating_manager:

CGP Officer — full access to every CGP record
CGP Designated Official — implies CGP Officer; top-level accountable person named in the PSPC registration

ir.rule records enforce that PSA and Security Incident records are visible only to CGP Officer and above — a regular plating manager cannot see them. No users are assigned by default; admin must grant access explicitly.

Security Plan template

On install the module seeds a fusion.plating.doc.control record titled "CGP Security Plan (Template)". Customise it to your facility and submit to PSPC as part of your registration.

Dependencies

fusion_plating_quality — for fusion.plating.doc.control
hr — for employee linkage on PSAs, AIs, and access logs

Reference

https://www.tpsgc-pwgsc.gc.ca/pmc-cgp/