vexplor_dev

Files

kmh 471704445b Add lock guard for work-instruction edit (production-acknowledged rows)

Implements the lock scenario originally designed in mhkim 79962160 that was
lost during the jskim-node merge. Production-acknowledged detail rows
(those with batch_id-matched work_order_process having work_order_process_result)
are protected from item/qty/routing changes and deletion during work-instruction edit.

Layer 1 — backend list SQL (2 locations, paginated + non-paginated):
- Add is_locked column via EXISTS subquery
  (wopr JOIN wop where wop.wo_id = wi.id AND wop.batch_id = d.id OR d.item_number)
- Leverages idx_wop_company_wo for performance

Layer 2 — backend save edit-mode rewrite (workInstructionController.ts:save):
1. Load existing detail rows with is_locked
2. Classify payload items: detailId match → updates, no match → inserts, missing in payload → deleteIds
3. Lock guard:
   - UPDATE: locked row item/qty/routing change → throw
   - DELETE: locked row → throw
4. work_instruction header UPDATE (existing)
5. deleteIds: cascade DELETE process_work_result → work_order_process → work_instruction_detail
6. updates: locked → schedule/equipment/worker only; unlocked → full + wop.plan_qty sync
7. inserts: standard INSERT (shared with new-mode path)

Layer 3 — frontend COMPANY_7 mapping:
- relatedDetails.map adds detailId: d.detail_id, locked: d.is_locked === true

Verification:
- backend npm run build PASS
- frontend tsc work-instruction file errors 0
- DB SQL simulation: COMPANY_7 CODE-00010 detail correctly identified as locked

Companion to previous commit (POP batch-id separation restoration). Together they
re-establish mhkim's original batch-aware work-instruction lifecycle.

Scope: COMPANY_7 only. COMPANY_8/9/10/16/28/29/30/31 frontend mapping pending verification.

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

2026-05-22 11:18:30 +09:00