[feril3]

Treasurer → Ketua/Admin transaction approval workflow

Implements the new operational requirement that financial changes submitted by Bendahara must be reviewed before posting.

Posting semantics

• Bendahara CREATE requests are staged outside the transactions table until approved
• Bendahara UPDATE requests keep the currently-approved transaction unchanged until approval
• Bendahara DELETE requests keep the transaction posted until approval
• Bendahara document replacements also require approval
• Ketua/Admin changes remain direct because that role is the reviewer

This means pending work does not affect:

• current balance
• dashboard
• reports / CSV
• Public Display
• recent posted transactions

Review flow

• Transactions page now includes Review Transaksi for Ketua/Admin
• Bendahara sees Pengajuan Saya
• reviewer can Approve & posting or Minta revisi
• revision requires a Ketua note
• Bendahara can correct amount/date/method/category/description and replace evidence/mutation before resubmitting
• reviewer can open pending evidence and bank mutation
• UPDATE review shows Saat ini vs Usulan

Data integrity

• new transaction_approval_requests table stores staged proposals
• one active UPDATE/DELETE request per posted transaction
• approved historical transactions stay stable while changes are pending
• stale-version guard prevents an old request from overwriting a transaction that changed after submission
• delete approval history survives transaction deletion
• replaced Drive files are cleaned after an approved document change
• all submit/revise/resubmit/approve/document-update events are audit logged

Roles

• existing backend role ADMIN is retained for compatibility
• user-facing label is clarified as Ketua / Admin
• TREASURER remains Bendahara

Regression coverage

Integration tests cover:

1. Treasurer submits new income → HTTP 202 and not posted
2. Ketua asks revision with note
3. Treasurer corrects + resubmits
4. Ketua approves → transaction becomes posted
5. Treasurer edits approved transaction → old amount remains posted
6. approval atomically applies the new amount
7. Treasurer delete → transaction remains until Ketua approval
8. approved delete finally removes it

Source regressions also lock review UI, attachment review, conflict guards, and role-aware form copy.