Add confirmation step for irreversible transitions in ApprovalActionSheet

epic-expense-approval-workflow-bulk-and-action-task-009 — Implement the two-step confirmation flow within ApprovalActionSheet so coordinators must explicitly confirm before any irreversible approve or reject transition is committed. Show a summary of the action including claim identifier and decision. Confirmation button must be distinct from the initial action button to prevent accidental activation.

high priority low complexity frontend pending frontend specialist Tier 2

Acceptance Criteria

Tapping Approve or Reject (with valid comment for reject) transitions the sheet to a confirmation step — no API call is made at this point

The confirmation step displays a clear summary: action type ('Approve' or 'Reject'), claim identifier, claimant name, and rejection comment (if rejecting)

Confirmation step shows two buttons: 'Confirm [Approve/Reject]' (primary) and 'Go back' (secondary/text button)

The 'Confirm' button uses a visually distinct style from the initial action buttons — different label, different visual weight — to prevent confusion

For reject, the confirmation summary includes the rejection comment text so the coordinator can review before committing

Tapping 'Go back' returns to the first step with all previously entered data preserved (comment text not cleared)

The confirmation step is not dismissible via scrim or drag (same as scaffold behavior)

Confirmation step transition uses AnimatedSwitcher or equivalent — no hard cut between steps

Screen readers announce the confirmation step heading when it appears (Semantics with liveRegion or focus shift to heading)

Step indicator or heading clearly communicates 'Step 2 of 2' or equivalent so users understand they are in a multi-step flow

Technical Requirements

frameworks

Flutter

BLoC

data models

claim_event

performance requirements

Step transition animation must complete in under 250ms to feel responsive

security requirements

Confirmation step must re-display the rejection comment to allow coordinator review — prevents unintended reason submission

ui components

AnimatedSwitcher or IndexedStack for step transition

ConfirmationSummaryWidget (sub-widget showing action details)

AppButton (confirm variant, go-back variant)

Semantics with autofocus or requestFocus on confirmation heading

Execution Context

Execution Tier

Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

View Full Execution Plan

Implementation Notes

Model the two-step flow with an enum: enum ApprovalSheetStep { action, confirmation }. Store this as local StatefulWidget state (setState). Use AnimatedSwitcher with a CrossFadeTransition for smooth step changes. The ConfirmationSummaryWidget should be a pure display widget receiving action type, claim ID, claimant name, and comment as constructor params — no business logic inside.

Use FocusScope to shift focus to the confirmation heading widget after transition so VoiceOver/TalkBack reads it immediately. The 'Confirm' button label should be explicit: 'Confirm Approval' or 'Confirm Rejection' — not a generic 'Confirm'. This prevents the UX ambiguity described in the requirements.

Testing Requirements

Widget tests: (1) tapping Approve with no comment transitions to confirmation step showing 'Approve' action; (2) tapping Reject with valid comment transitions to confirmation showing comment text; (3) tapping Go back returns to step 1 with comment text preserved in controller; (4) confirmation step does not trigger any service call — verify no Bloc events emitted; (5) confirmation heading widget is present in widget tree after transition. Use WidgetTester.tap, pump, and find.text assertions.

Component

Approval Action Bottom Sheet

ui medium

Dependencies (1)

Add validation logic to ApprovalActionSheet that requires a non-empty rejection comment before the reject action can be confirmed. Display inline error messaging when the coordinator attempts to confirm rejection without a comment. Rejection comment field must be visually prominent and focused automatically when reject action is tapped. epic-expense-approval-workflow-bulk-and-action-task-008

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