Implement approve/reject decision submission with coordinator comment
epic-travel-expense-registration-core-services-task-009 — Add the decision submission method to the expense attestation service: acceptClaim(claimId, {comment?}) and rejectClaim(claimId, {comment}). Each method must update the claim record in Supabase via ExpenseRepository, record the coordinator decision and optional comment, and trigger claimant notification dispatch. Rejection must require a non-empty comment per HLF policy.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
Wrap the claim UPDATE and ClaimEvent INSERT in a Supabase RPC (Postgres function) to ensure atomicity — do not do two separate REST calls for this because a partial write (claim updated, event not written) would corrupt the audit trail. The RPC should accept (p_claim_id uuid, p_decision text, p_comment text, p_actor_id uuid) and return the updated claim row. Validate comment emptiness in Dart before calling the RPC to give immediate UI feedback. For notification dispatch, call an Edge Function by name using supabase.functions.invoke('dispatch-claim-decision-notification', body: {...}) without awaiting — catch and log any error silently.
After a successful decision, use ref.read(attestationQueueProvider.notifier).removeClaim(claimId) for the optimistic update rather than invalidating the entire provider.
Testing Requirements
Unit tests with fake ExpenseRepository and fake NotificationDispatcher: (1) acceptClaim happy path — status updated, ClaimEvent written, notification dispatched, claim removed from notifier state; (2) rejectClaim with empty comment — throws ValidationException, no network calls made; (3) rejectClaim with valid comment — full success path; (4) Supabase update throws — AlreadyDecidedException returned when claim status is not pending-attestation; (5) network failure during update — no ClaimEvent written, original queue state preserved. Use flutter_test with mockito or manual fakes. Integration test: verify claim_events row is inserted with correct from/to status values.
Mutual exclusion rules are stored in the expense type catalogue's exclusive_groups field. If the catalogue schema or group definitions differ between HLF and Blindeforbundet, the validation service must handle multiple group configurations without hardcoding organisation-specific logic.
Mitigation & Contingency
Mitigation: Design the validation service to be purely data-driven: it reads exclusive_groups from the cached catalogue and enforces whichever groups are defined, with no hardcoded organisation names. Write parameterised unit tests covering at least 4 different catalogue configurations to verify generality.
Contingency: If an organisation requires non-standard exclusion semantics (e.g. partial exclusion within a group), introduce an exclusion_type field to the catalogue schema and extend the service, treating it as a catalogue configuration change rather than a code fork.
The attestation service subscribes to Supabase Realtime for live queue updates. On mobile, Realtime WebSocket connections can be dropped during network transitions, causing the coordinator queue to become stale without the user being aware.
Mitigation & Contingency
Mitigation: Implement connection lifecycle management: reconnect on network-change events, show a 'reconnecting' indicator when the subscription is broken, and perform a full queue refresh on reconnect rather than relying solely on delta events.
Contingency: Add a manual pull-to-refresh gesture on the attestation queue screen as a guaranteed fallback. If Realtime proves unreliable in production, switch to periodic polling (30-second interval) as a degraded but functional mode.
If a peer mentor submits a draft while offline and then submits the same claim again after connectivity is restored (thinking the first attempt failed), duplicate claims may be persisted in Supabase.
Mitigation & Contingency
Mitigation: Assign a client-generated idempotency key (UUID) to each draft at creation time. The submission service sends this key as an upsert key to Supabase, preventing duplicate inserts. The draft is marked 'submitted' locally after first successful upload.
Contingency: Implement a server-side duplicate detection trigger on the expense_claims table checking (activity_id, claimant_id, created_date) within a 24-hour window and returning the existing record ID rather than inserting a duplicate.