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>
85 lines
4.2 KiB
XML
85 lines
4.2 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!--
|
|
Copyright 2026 Nexa Systems Inc.
|
|
License OPL-1 (Odoo Proprietary License v1.0)
|
|
Part of the Fusion Plating product family.
|
|
-->
|
|
<odoo>
|
|
|
|
<record id="view_partner_form_account_hold" model="ir.ui.view">
|
|
<field name="name">res.partner.form.fp.account.hold</field>
|
|
<field name="model">res.partner</field>
|
|
<field name="inherit_id" ref="base.view_partner_form"/>
|
|
<field name="arch" type="xml">
|
|
<xpath expr="//sheet" position="before">
|
|
<div class="alert alert-danger mb-0" role="alert"
|
|
invisible="not x_fc_account_hold">
|
|
<strong>Account Hold Active</strong> —
|
|
<field name="x_fc_account_hold_reason" readonly="1" nolabel="1"/>
|
|
<br/>
|
|
<small>
|
|
Placed by <field name="x_fc_account_hold_by_id" readonly="1" nolabel="1"/>
|
|
on <field name="x_fc_account_hold_date" readonly="1" nolabel="1"/>
|
|
</small>
|
|
</div>
|
|
</xpath>
|
|
|
|
<!-- Single "Plating Defaults" tab — invoice strategy, delivery,
|
|
deadlines, tax type, payment terms. Set once here, cascades
|
|
onto every new SO for this customer. -->
|
|
<xpath expr="//notebook" position="inside">
|
|
<page string="Plating Defaults" name="fp_plating_defaults_tab"
|
|
invisible="is_company == False and parent_id"
|
|
groups="fusion_plating_invoicing.group_fp_accounting">
|
|
<p class="text-muted">
|
|
Set defaults once per customer to speed up order entry.
|
|
These cascade onto every new sale order; the estimator
|
|
can override per order.
|
|
</p>
|
|
<group>
|
|
<group string="Invoicing">
|
|
<field name="x_fc_default_invoice_strategy"/>
|
|
<field name="x_fc_default_deposit_percent"
|
|
invisible="x_fc_default_invoice_strategy != 'deposit'"/>
|
|
<field name="property_payment_term_id"/>
|
|
<field name="property_account_position_id"
|
|
string="Tax Type (Fiscal Position)"/>
|
|
</group>
|
|
<group string="Fulfilment">
|
|
<field name="x_fc_default_delivery_method"/>
|
|
<field name="x_fc_default_internal_deadline_days"/>
|
|
<field name="x_fc_default_customer_deadline_days"/>
|
|
</group>
|
|
</group>
|
|
</page>
|
|
|
|
<!-- Phase D5 — Account Hold management (the override gate per
|
|
spec section 2.E Layer 3). Was previously gated on the
|
|
fold-in group_fp_accounting; consolidated to group_fp_manager
|
|
and resolves audit-finding-11 _administrator typo by removing
|
|
the old fold-in group from this surface. The Python helper
|
|
_fp_user_can_override_account_hold (still in res_partner.py)
|
|
is the runtime gate; Phase G fixes the Python-side typo
|
|
separately. -->
|
|
<page string="Account Hold" name="account_hold_tab"
|
|
groups="fusion_plating.group_fp_manager">
|
|
<group>
|
|
<group>
|
|
<field name="x_fc_account_hold"/>
|
|
<field name="x_fc_account_hold_reason"
|
|
invisible="not x_fc_account_hold"/>
|
|
</group>
|
|
<group>
|
|
<field name="x_fc_account_hold_date"
|
|
invisible="not x_fc_account_hold"/>
|
|
<field name="x_fc_account_hold_by_id"
|
|
invisible="not x_fc_account_hold"/>
|
|
</group>
|
|
</group>
|
|
</page>
|
|
</xpath>
|
|
</field>
|
|
</record>
|
|
|
|
</odoo>
|