Account activation/deactivation toggle
epic-admin-portal-user-management-task-008 — Implement the account activation and deactivation toggle on each user row. Toggle must call UserManagementService to update account status, display optimistic UI update, handle errors with revert and user-facing message, and require a confirmation step to prevent accidental deactivation.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Implementation Notes
Implement ActivationToggleWidget as a StatelessWidget that accepts the current AccountStatus and an onToggle callback — keep it decoupled from the BLoC so it is independently testable. The BLoC integration lives in the parent UserRowWidget which dispatches ActivationToggled on the callback. For the confirmation dialog, use `showDialog` with a simple AlertDialog — do not navigate to a new route, as that would disrupt the list scroll position. The own-user guard: compare the row's userId against the authenticated admin's userId from the auth state (available via Supabase auth or a separate BLoC); if they match, render the toggle as disabled with a Tooltip.
For the optimistic update and revert pattern, ensure the BLoC's operationStatus carries the previous status so revert is deterministic — do not rely on re-fetching from the server to revert, as that introduces latency and a potential second error. Use design token colours for the toggle states: active = `AppColors.success` / `AppColors.primary`, inactive = `AppColors.surfaceVariant`.
Testing Requirements
Widget tests: render active user row and tap toggle — assert confirmation dialog appears; dismiss dialog — assert no event dispatched and toggle reverts; confirm dialog — assert ActivationToggled event dispatched; render inactive user row and tap toggle — assert NO confirmation dialog; assert toggle disabled when operationStatus is InProgress for that userId; assert own-user toggle is disabled. BLoC integration: toggle active user → optimistic inactive → server error → reverts to active with error snackbar. Accessibility: assert semantic label changes from 'Deactivate user' to 'Activate user' after toggle. Golden test for toggle in active, inactive, and in-progress states.
Displaying NHF users with membership in up to 5 local chapters in a flat list view without duplicating entries requires a non-trivial aggregation query. Incorrect query design could result in duplicated user rows or missing chapter affiliations, confusing admins and causing incorrect role assignments.
Mitigation & Contingency
Mitigation: Design the user list query to GROUP BY user_id and aggregate chapter affiliations as an array field. Use AdminRepository's typed models to surface this aggregated structure to the UI. Validate with a test dataset containing users in 5 chapters.
Contingency: If aggregation query complexity proves too high for real-time filtering, implement a separate multi-chapter affiliation fetch triggered only when a specific user row is expanded, reducing query complexity for the base list.
Composable multi-dimensional filters (role + chapter + status + certification state) applied server-side against an org with 2,000+ users may produce slow queries, particularly when filtering by certification state requires joining an additional table.
Mitigation & Contingency
Mitigation: Ensure the relevant filter columns (role, status, chapter_id, certification_expiry) are indexed in Supabase. Use cursor-based pagination rather than OFFSET to maintain consistent performance at high page numbers. Profile filter query combinations against a large dataset during development.
Contingency: If multi-filter performance degrades in production, introduce a denormalised search index table updated on user status changes, allowing the list query to filter from a single table.
Deactivating a user account that has ongoing activity assignments, open expense claims, or active chapter affiliations may leave orphaned records or break downstream workflows if the deactivation does not trigger correct cascade handling.
Mitigation & Contingency
Mitigation: Define and document the expected state of each dependent record type on user deactivation before implementing the toggle. Implement deactivation as a UserManagementService operation that checks for and warns about open dependencies before persisting. Write integration tests covering each dependency type.
Contingency: If orphaned record issues are discovered post-launch, provide an admin-accessible reconciliation view that surfaces users with inconsistent dependency states and allows manual resolution without requiring a code deploy.