niteshandClaude Sonnet 5
a65d801250
- Client activation now requires a different user than the one who created the client
(client.getCreatedBy() vs current user) — no bypass, including CHECKER_SUPER_USER, since a
bypass would recreate the exact "role bypasses the hold" loophole this closes. Client creation
itself is unaffected (the wizard needs a real client id immediately for photo/KYC/address/family
follow-up uploads), only activation is gated.
- New maker-checker queue for Client edits, modelled on this codebase's existing
m_share_account_pending_edit / chequebook patterns rather than Fineract's native
command-approval engine (which any ALL_FUNCTIONS role bypasses unconditionally):
- m_client_pending_edit (migrations 0429-0431): stores the maker's raw edit payload plus a
point-in-time "before" snapshot (original_json, extracted from the frontend's _originalValues
key) so the checker's diff stays accurate even after the edit is approved/rejected, when the
live client no longer reflects the pre-edit state.
- ClientEditWritePlatformService: submitEditForApproval() stages the edit (refusing a second
submission while one's already pending, via a nullable-but-unique pending_lock_key);
approveEdit() replays the payload through the existing updateClient() so all of Client's
validation/change-detection runs unchanged, just deferred; rejectEdit() discards it. The maker
can never approve/reject their own submission.
- ClientEditApiResource: /clients/{id}/edit (submit), /clients/edit/pending (paginated +
status/clientName/date-range filterable list, mirrors /chequebook/pending-requests),
/clients/{id}/edit/approve, /clients/{id}/edit/reject. New permissions (migration 0430):
SUBMITEDIT_CLIENT, APPROVEEDIT_CLIENT, REJECTEDIT_CLIENT, APPROVEEDIT_CLIENT_CHECKER (the
last one surfaces pending edits in the generic Checker Inbox too).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>