Implement Coordinator Review Queue Screen with E2E Integration Tests
epic-expense-approval-workflow-coordinator-ui-task-014 — Build the CoordinatorReviewQueueScreen as the primary coordinator entry point. Render paginated list of pending claims with per-claim summary cards (submitter name, total, expense types, date, ClaimStatusBadge). Implement multi-select checkbox state including cross-page selection tracking, integrate BulkApprovalBar for batch actions, navigate to ApprovalActionBottomSheet for single-claim review, subscribe to RealtimeApprovalSubscription for live queue updates, and provide filter/sort controls by date, amount, and expense type. Write end-to-end integration tests covering the full pipeline: peer mentor submission → threshold evaluation → auto-approval or queue entry → coordinator review → notification delivery → audit timeline display.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
Model the screen's BLoC as CoordinatorReviewQueueBloc with a CoordinatorReviewQueueState containing: List
For realtime, subscribe to Supabase channel in the BLoC's constructor and add RealtimeClaimAdded events; cancel subscription in close(). For the E2E tests, use flutter_test's pumpAndSettle with a custom timeout and poll the Supabase DB directly to assert audit records. The filter/sort sheet should be a separate stateless widget receiving current filter/sort values and emitting new ones via callback — keep it decoupled from the BLoC.
Testing Requirements
Unit tests (flutter_test): CoordinatorReviewQueueBloc — test LoadQueue, LoadNextPage, SelectClaim, DeselectClaim, SelectAll, ClearSelection, ApplyFilters, ApplySortOrder, RealtimeClaimAdded events and their resulting states. Mock all repository and service dependencies. Widget tests: render queue with 3 fixture claims and assert card content; tap a card and assert bottom sheet is shown; select 2 claims and assert BulkApprovalBar appears with count=2; apply a date filter and assert filtered list. Integration tests (flutter_test with Supabase test environment): full E2E pipeline as specified in acceptance criteria #12 — use a dedicated test Supabase project with seeded data; verify realtime latency <2s; verify notification delivery.
TestFlight distribution: include this screen in the first TestFlight build for coordinator beta testers across HLF and NHF.
Maintaining multi-select state across paginated list pages is architecturally complex in Flutter with Riverpod/BLoC. If the selection state is stored in the widget tree rather than the state layer, page transitions and list redraws can silently clear selections, causing coordinators to lose their multi-select and re-enter it.
Mitigation & Contingency
Mitigation: Store the selected claim ID set in a dedicated Riverpod StateNotifier outside the paginated list widget tree. The paginated list reads selection state from this provider and does not own it. Selection persists independently of list scroll position or page loads.
Contingency: If cross-page selection proves prohibitively complex, limit bulk selection to the currently visible page (add a clear warning in the UI) and prioritise single-page bulk approval for the initial release.
If a coordinator has the queue open while another coordinator approves claims from the same queue (possible in large organisations with shared chapter coverage), the Realtime update may arrive out of order or be missed during a reconnect, leaving the first coordinator's view stale and allowing them to attempt to approve an already-actioned claim.
Mitigation & Contingency
Mitigation: The ApprovalWorkflowService's optimistic locking (from the foundation epic) will catch the concurrent edit at the database level. The CoordinatorReviewQueueScreen should handle the resulting ConcurrencyException by removing the claim from the local list and showing a brief snackbar: 'This claim was already actioned by another coordinator.'
Contingency: Add a queue staleness indicator (a subtle 'last updated X seconds ago' label) and a manual refresh button as a fallback for coordinators who notice inconsistencies.
The end-to-end test requirement that a peer mentor receives a push notification within 30 seconds of coordinator approval depends on FCM delivery latency, which is outside the application's control and can vary significantly in CI/CD environments.
Mitigation & Contingency
Mitigation: Structure end-to-end tests to verify notification intent (correct FCM payload dispatched, correct Realtime event emitted) rather than actual device delivery timing. Use test doubles for FCM delivery in automated tests and reserve real-device delivery tests for manual pre-release validation.
Contingency: If notification timing requirements must be validated in automation, instrument the ApprovalNotificationService with a test hook that records dispatch timestamps and assert against those rather than actual FCM callbacks.