docs(plating): implementation plan for technician receiving + shipping tablet
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:
File diff suppressed because it is too large
Load Diff
@@ -58,7 +58,7 @@ surface), instead of those actions being Shop-Manager+/back-office only.
|
|||||||
|
|
||||||
## Design
|
## 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`
|
`fusion_plating_receiving/security/ir.model.access.csv` — flip `perm_write` + `perm_create`
|
||||||
`0 → 1` on the three Technician rows:
|
`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
|
**Version bumps:** `fusion_plating_receiving` + `fusion_plating_logistics` manifest versions
|
||||||
(ACL rows only reload on `-u` when the version changes).
|
(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
|
- Tech taps a card in the **Receiving** column → workspace opens → the existing receiving
|
||||||
panel renders from the `receivings` payload.
|
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;
|
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.
|
counting/closing clears all sibling job cards from Receiving together.
|
||||||
- **Attribution:** the endpoints already run as `request.env.user` (the tech);
|
- **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
|
`received_by_id = env.user` and chatter is authored by the tech. The receiving-record
|
||||||
now-granted ACL is what makes the write legal.
|
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` /
|
**Acceptance:** a user holding only `group_fp_technician` can call `receiving_save_lines` /
|
||||||
`receiving_mark_counted` / `receiving_close` / `damage_create` without `AccessError`.
|
`receiving_mark_counted` / `receiving_close` / `damage_create` without `AccessError`.
|
||||||
|
|||||||
Reference in New Issue
Block a user