Implement confirmation dialog before tenant context swap

epic-organization-selection-and-onboarding-ui-task-007 — When a user taps a non-active org in MultiOrgContextSwitcher, show a modal confirmation dialog before executing the tenant swap. The dialog must display the name of the org being switched to, warn the user that their current context will change, and offer Confirm and Cancel actions. Only on confirmation should TenantContextService.switchTenant() be called. Accidental dismissal (back gesture, tap outside) should cancel without switching.

high priority medium complexity frontend pending frontend specialist Tier 4

Acceptance Criteria

Tapping a non-active org in MultiOrgContextSwitcher opens a modal confirmation dialog (not an inline UI change)

The dialog title displays the org name being switched to (e.g., 'Switch to [Org Name]?')

The dialog body contains a plain-language warning that the current context will change

The dialog presents two actions: 'Confirm' (primary, accent color) and 'Cancel' (secondary/text button)

Tapping 'Confirm' closes the dialog and proceeds to task-008 (calls TenantContextService.switchTenant())

Tapping 'Cancel' closes the dialog and returns to the switcher list with no state change

Tapping outside the dialog (barrier tap) cancels without switching (barrierDismissible: false OR same cancel behavior)

Android back gesture dismisses the dialog without switching

The dialog is not shown when tapping the currently active org

All dialog strings (title template, body warning, button labels) are defined in localization files — no hardcoded strings

Widget test verifies dialog appears on inactive org tap, does not appear on active org tap, and each action produces the correct outcome

Technical Requirements

frameworks

Flutter

flutter_bloc

data models

Organization (orgId, orgName for display in dialog)

performance requirements

Dialog must open synchronously on tap — no async operation before showing the dialog

security requirements

The org name displayed in the dialog must come from the already-fetched membership list — not re-fetched or constructed from user input

ui components

AlertDialog or custom confirmation dialog widget

Primary TextButton / ElevatedButton for Confirm

Secondary TextButton for Cancel

Localized strings via AppLocalizations

Execution Context

Execution Tier

Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

View Full Execution Plan

Implementation Notes

Show the dialog using showDialog() and await the result: true for confirm, false/null for cancel. This keeps the dialog logic self-contained in the gesture handler or BlocListener — no separate 'awaiting confirmation' Cubit state is needed, simplifying the state machine. Pass barrierDismissible: false and handle the back gesture by wrapping the dialog content in a PopScope (Flutter 3.16+) or WillPopScope to return false (cancel). Construct the dialog as a reusable ConfirmSwitchOrgDialog widget that accepts orgName as a parameter and returns the confirm/cancel decision.

Dispatch the ConfirmOrgSwitch(orgId) event to the MultiOrgContextSwitcherCubit only when the dialog returns true. Keep TenantContextService call out of the dialog itself — the dialog only returns a boolean decision.

Testing Requirements

Write widget tests: (1) tapping inactive org shows confirmation dialog with correct org name, (2) tapping active org does not show dialog, (3) tapping Confirm closes dialog and emits ConfirmOrgSwitch event to Cubit, (4) tapping Cancel closes dialog and Cubit remains in MultiOrgLoaded state (no switch initiated), (5) back gesture dismisses dialog without switching. Write Cubit unit test: (6) ConfirmOrgSwitch event triggers switchTenant call, (7) no switch occurs without explicit confirmation. Use flutter_test and bloc_test.

Component

Multi-Organization Context Switcher

ui medium

Dependencies (1)

Create the MultiOrgContextSwitcher widget. On open, call MultiOrgMembershipResolver to retrieve all organizations the authenticated user belongs to. Render each org as a selectable list item using OrgCardWidget, clearly marking the currently active org with a visual highlight indicator (checkmark icon and accent color). The switcher must be accessible from the settings/hamburger menu. Show a loading skeleton while memberships are being fetched. epic-organization-selection-and-onboarding-ui-task-006

Epic Risks (2)

low impact high prob technical

OrgSelectionScreen and OrgContextSwitcher render partner-specific logos, colors, and text from dynamic data. Golden tests (pixel-comparison screenshots) will fail whenever branding assets are updated in the backend, causing CI failures that block unrelated PRs and eroding developer trust in the test suite.

Mitigation & Contingency

Mitigation: Use fixture-based golden tests with static mock Organization models containing embedded test assets rather than network-fetched assets. Separate branding asset acceptance tests into a dedicated CI job that only runs on branding-related PRs and is maintained by the design team.

Contingency: If golden test maintenance overhead becomes excessive, replace pixel-comparison goldens with semantic widget tests that assert widget tree structure and key property values, reserving golden tests for only the most stable, design-critical elements.

high impact medium prob scope

Several partner organizations (especially Blindeforbundet) have users who rely entirely on VoiceOver or TalkBack. Complex branded card layouts with overlaid logos, names, and selection states are notoriously difficult to make fully accessible; missing semantics or incorrect focus order could make the selection screen completely unusable for screen reader users before launch.

Mitigation & Contingency

Mitigation: Involve an accessibility specialist in the design review before any widget implementation begins. Use Flutter's Semantics widget with explicit label, hint, and button role on OrgCardWidget. Conduct manual screen reader testing on both iOS (VoiceOver) and Android (TalkBack) for every sprint that touches these screens, not just before release.

Contingency: If full WCAG compliance cannot be achieved within the sprint, implement a simplified text-list fallback mode that activates when the system detects an active screen reader, presenting orgs as plain accessible list tiles instead of the branded card layout.

Quick Links

All Tasks Execution Plan