🏠 Overview › ✅ Implementation Tasks ›✅ epic-expense-approval-workflow-bulk-and-action-task-005

Wire BulkApprovalBar selection state management

epic-expense-approval-workflow-bulk-and-action-task-005 — Connect BulkApprovalBar to the coordinator review queue selection state using Riverpod or BLoC. Bar must reactively show/hide based on whether any claims are selected, update the count badge on selection change, and disable action buttons during in-progress batch processing to prevent duplicate submissions.

high priority medium complexity frontend pending frontend specialist Tier 1

Acceptance Criteria

A Riverpod StateNotifierProvider (or BLoC) manages selectedClaimIds (Set<String>) and isBulkProcessing (bool) for the coordinator review queue screen
BulkApprovalBar receives selectedCount derived from selectedClaimIds.length — no direct Set reference passed to widget
Tapping a claim row in the review queue toggles its ID in selectedClaimIds — verified with a widget test
A 'Select All' checkbox/button in the queue header adds all visible claim IDs to selectedClaimIds
Clearing all selections (deselect all or deselect last item) hides the BulkApprovalBar via animation
isBulkProcessing is set to true when batch action starts and false when BulkApprovalResult is received
During isBulkProcessing=true: claim row checkboxes are also disabled to prevent selection changes mid-batch
After batch completes successfully, selectedClaimIds is cleared automatically
After partial failure, selectedClaimIds retains only the failed claim IDs so coordinator can retry or deselect manually
State is scoped to the coordinator review queue screen — disposed on screen pop
State provider is unit-testable in isolation from the widget tree

Technical Requirements

frameworks
Flutter
Riverpod
BLoC
Dart
data models
assignment
performance requirements
Selecting/deselecting a single claim must not rebuild the entire claim list — use select() or Selector to scope rebuilds to BulkApprovalBar and the toggled row only
Set<String> used for O(1) contains/toggle operations — not List
security requirements
selectedClaimIds must only contain UUIDs of claims belonging to the current coordinator's organization — validated before populating the queue
ui components
Checkbox widget on each claim row for selection toggle
Select All control in queue list header
BulkApprovalBar (from task-004)

Execution Context

Execution Tier
Tier 1

Tier 1 - 540 tasks

Can start after Tier 0 completes

Implementation Notes

Use Riverpod's StateNotifierProvider.autoDispose to ensure state is cleaned up when the coordinator queue screen is popped. Define a ClaimSelectionState class with selectedClaimIds (Set) and isBulkProcessing (bool) — avoid using two separate providers that can get out of sync. The partial-failure behavior (retain failed IDs) requires passing the BulkApprovalResult into the notifier's onBatchComplete method — design this method before wiring the processor in task-006. Avoid storing the full claim objects in the selection state — only IDs.

This keeps the state small and avoids stale data issues if the claim list refreshes during processing.

Testing Requirements

Unit tests on StateNotifier/BLoC: (1) toggle adds then removes same ID correctly, (2) selectAll adds all provided IDs, (3) clearSelection empties the set, (4) setProcessing(true) sets isBulkProcessing and (5) setProcessing(false) clears it, (6) onBatchComplete(result) clears all IDs on full success, (7) onBatchComplete(result) retains failed IDs on partial failure. Widget integration tests: (1) tap a claim row and verify BulkApprovalBar appears with count 1, (2) tap same row again and verify bar disappears, (3) verify checkboxes disabled during isProcessing=true. Use flutter_test with ProviderContainer for state tests.

Component
Bulk Approval Action Bar
ui low
Dependencies (1)
Implement the BulkApprovalBar as a sticky bottom widget that becomes visible when one or more claims are selected in the coordinator review queue. Display selected claim count, provide Approve All and Reject All action buttons, and emit events to trigger BulkApprovalProcessor. Widget must remain anchored above the bottom navigation bar. epic-expense-approval-workflow-bulk-and-action-task-004
Epic Risks (2)
medium impact medium prob scope

If a bulk approval batch partially fails (some claims approved, some failed), the UI must communicate which specific claims failed without overwhelming the coordinator. A poorly designed error display could cause coordinators to re-approve already-approved claims or miss claims that still need attention.

Mitigation & Contingency

Mitigation: Design the BulkApprovalResult display to show a clear summary (e.g., '14 approved, 2 failed') with a collapsible list of failed claims including their IDs and submitter names. Failed claims should remain selected in the queue so the coordinator can retry them individually.

Contingency: If the summary UI proves insufficient, add a dedicated 'bulk action history' sheet showing the last bulk operation result, accessible from the queue screen header.

medium impact low prob technical

If the app is backgrounded or the network drops while the coordinator has the ApprovalActionSheet open mid-decision, the typed comment could be lost and the transition state could be ambiguous, potentially causing a coordinator to believe they approved a claim that was never submitted.

Mitigation & Contingency

Mitigation: Persist the in-progress action sheet state (selected action + comment text) to a local draft store keyed on claim ID. On sheet re-open for the same claim, restore the draft. After confirmed submission, verify the resulting claim status from the server before dismissing the sheet.

Contingency: On network error during submission, display a persistent retry banner within the sheet rather than dismissing it, so the coordinator can resubmit without re-entering their comment.

Quick Links
All Tasks Execution Plan