admin/Odoo-Modules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(plating): implementation plan for technician receiving + shipping tablet

Browse Source 
Bite-sized TDD plan across receiving ACL+sudo, delivery ACL, fp.job
ship-readiness helpers, shipping endpoints, and the workspace shipping
panel. Also patches the spec to record the sale.order status-write sudo
fix found during planning.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
gsinghpal
2026-05-29 00:50:23 -04:00
parent df0de97a68
commit b98ee8a6fb
2 changed files with 1034 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
fusion_plating/docs/superpowers/specs/2026-05-29-technician-receiving-shipping-tablet-design.md
View File

@@ -58,7 +58,7 @@ surface), instead of those actions being Shop-Manager+/back-office only.
## Design
### 1. Permissions (ACL changes only — no new groups)
### 1. Permissions (ACL changes + one `sudo()` — no new groups)
`fusion_plating_receiving/security/ir.model.access.csv` — flip `perm_write` + `perm_create`
`0 → 1` on the three Technician rows:
@@ -81,9 +81,14 @@ Leave the vehicle / pickup / route / route-stop Technician rows **read-only**.
**Version bumps:** `fusion_plating_receiving` + `fusion_plating_logistics` manifest versions
(ACL rows only reload on `-u` when the version changes).
### 2. Receiving on the tablet (ACL-only; UI + endpoints already exist)
### 2. Receiving on the tablet (ACL + one `sudo()`; UI + endpoints already exist)
**No code change beyond §1.** After the ACL flip:
**ACL flip (§1) + one `sudo()`.** `action_mark_counted` / `action_close` call
`_update_so_receiving_status`, which writes `sale.order.x_fc_receiving_status` directly — a
technician lacks `sale.order` write, so that internal denormalized-status write must be
elevated (`rec.sale_order_id.sudo()…`). Without it the ACL flip alone still AccessErrors
inside mark-counted. (Discovered during planning; the rest of the receiving UI + endpoints
are untouched.) After both changes:
- Tech taps a card in the **Receiving** column → workspace opens → the existing receiving
panel renders from the `receivings` payload.
@@ -95,8 +100,9 @@ Leave the vehicle / pickup / route / route-stop Technician rows **read-only**.
order), so the panel is identical regardless of which sibling job's card was tapped;
counting/closing clears all sibling job cards from Receiving together.
- **Attribution:** the endpoints already run as `request.env.user` (the tech);
`received_by_id = env.user` and chatter is authored by the tech. No `sudo` — the
now-granted ACL is what makes the write legal.
`received_by_id = env.user` and chatter is authored by the tech. The receiving-record
writes go through the now-granted ACL; only the internal `sale.order` status write inside
`_update_so_receiving_status` is `sudo()`'d (denormalized status, never user-entered).
**Acceptance:** a user holding only `group_fp_technician` can call `receiving_save_lines` /
`receiving_mark_counted` / `receiving_close` / `damage_create` without `AccessError`.