feat(plating-landing): role-based dispatch resolver + picklist expansion
Phase E of permissions overhaul. The landing resolver now dispatches based on the user's highest role (per spec Section 3): Owner -> Manager Desk Quality Mgr -> Quality Dashboard Manager -> Manager Desk Sales Manager -> Sale Orders Shop Manager -> Plant Kanban (v2 layout) or Workstation (legacy) Sales Rep -> Quotations Technician -> Plant Kanban / Workstation User override (x_fc_plating_landing_action_id) still wins; company default and hardcoded Sale Orders are fallbacks. Layout-flag-aware via ir.config_parameter['fusion_plating_shopfloor.layout'] (v2 vs legacy). x_fc_pickable_landing field added to BOTH ir.actions.act_window AND ir.actions.client (Manager Desk / Plant Kanban / Quality Dashboard are client actions). Resolver helper polymorphically calls _render_resolved() on either model. Tagged 3 of 4 new actions pickable: Manager Desk, Plant Kanban, Quality Dashboard. (action_fp_shopfloor_landing doesn't exist as an XML record — it's a JS component name only; legacy layout falls through to company default gracefully via raise_if_not_found=False.) Tightened picklist domain to filter by user accessibility (Technician no longer sees Manager Desk in the dropdown). New compute field res.users.accessible_landing_action_ids runs check_access_rights on each pickable action. Tests in fusion_plating/tests/test_landing_resolver.py. CLAUDE.md updated with two durable rules: - x_fc_pickable_landing lives on BOTH act_window and actions.client - Role-based dispatch precedence and helper API Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1550,6 +1550,8 @@ Customer feedback: "too many top-level menus" + "configuration is unorganized".
|
||||
- Settings → Fusion Plating → Plating Landing Page block (company default).
|
||||
- `fusion_plating_configurator`'s earlier menu_fp_root override (action_fp_sale_orders direct) was removed — core's resolver now owns the routing.
|
||||
- Pickable list is curated via inline `<field name="x_fc_pickable_landing" eval="True"/>` on action records — currently flagged: `action_fp_sale_orders`, `action_fp_quotations`, `action_fp_process_recipe`. Add more by tagging the relevant act_window record at its source.
|
||||
- **`x_fc_pickable_landing` lives on BOTH `ir.actions.act_window` AND `ir.actions.client`** (added Phase E 2026-05-24). Client-action candidates like Manager Desk, Plant Kanban, and Quality Dashboard are pickable too. The resolver helper `ir.actions.act_window._fp_resolve_landing_for_current_user()` polymorphically calls `_render_resolved()` on either action model. When adding a new landing candidate, tag the right model (check whether the underlying `<record ... model="...">` is act_window or actions.client).
|
||||
- **Role-based dispatch** (Phase E): the resolver now reads `res.users` group membership and routes by precedence — Owner → Manager Desk; QM → Quality Dashboard; Manager → Manager Desk; Sales Manager → Sale Orders; Shop Manager → Plant Kanban/Workstation; Sales Rep → Quotations; Technician → Plant Kanban/Workstation. `_fp_workstation_action_for_layout()` reads `ir.config_parameter['fusion_plating_shopfloor.layout']` (v2 vs legacy) so flipping the flag retargets every Tech/Shop Manager on next page load. Per-user override still wins. Picklist domain is tightened via `res.users.accessible_landing_action_ids` (compute that runs `check_access_rights('read')` per pickable action) so a Tech can't pick "Manager Desk" they can't see.
|
||||
|
||||
### Phase 2 — Configuration sub-folder grouping (`fusion_plating` 19.0.11.1.0, commits `3641b78` + `62c1315` + `4671541`)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user