ActivityTypeFormScreen scaffold and routing
epic-activity-type-configuration-admin-interface-task-004 — Build the ActivityTypeFormScreen StatefulWidget with GoRouter integration supporting both creation mode (no argument) and edit mode (activityTypeId argument). Apply the established design token system and sidebar navigation conventions via HtmlGenerationUtils equivalent Flutter patterns. Wire the screen into the coordinator admin route tree with appropriate role guard. Initialise form state from the passed ActivityType when in edit mode.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Mirror the pattern of existing admin form screens in the project (e.g., edit contact screen) — use the same BlocProvider placement, same GoRouter extra/pathParameter conventions, and same loading/error widget approach. For the role guard, use GoRouter's redirect callback or a dedicated RoleGuard widget already in the project — do not duplicate the guard logic. In edit mode, pass the full ActivityType object as a GoRouter `extra` if navigating from the list screen (avoids a redundant network fetch); only fall back to fetching by ID when navigating via deep link. Use a CustomScrollView with SliverList so the AppBar collapses naturally on scroll — match the UX of other form screens.
The ActivityTypeFormBloc should be initialised with the ActivityType? argument in initState, not in the constructor, to support GoRouter's hot reload correctly.
Testing Requirements
Write widget tests in test/screens/admin/activity_type_form_screen_test.dart: (1) creation mode renders with correct AppBar title 'New Activity Type'; (2) edit mode renders with AppBar title containing the activity type display name after fetch; (3) a loading indicator is shown while the edit-mode fetch is in progress; (4) an error message and retry button are shown when the fetch fails; (5) a user without coordinator role is redirected to the no-access screen; (6) tapping cancel triggers navigation pop without saving; (7) the BLoC is properly provided and the screen rebuilds on state changes. Use a mock Supabase client for these widget tests. Write a GoRouter integration test asserting both routes resolve to ActivityTypeFormScreen.
The Bufdir reporting category list is defined externally by Bufdir and may change between reporting years. If the dropdown in ActivityTypeFormScreen is hardcoded, existing activity type mappings could become invalid after a Bufdir schema update, breaking export validation for all organisations.
Mitigation & Contingency
Mitigation: Store the valid Bufdir category list in a Supabase configuration table (bufdir_categories) rather than as a Dart constant, so it can be updated by an admin without a mobile app release. Load the list in the form screen via a lightweight repository call cached locally.
Contingency: If the Bufdir category list cannot be externalised before the admin screen ships, expose a manual override field that allows coordinators to enter a raw Bufdir category code as a fallback, and schedule the configuration table migration as a follow-up task.
Reusing ActivityTypeFormScreen for both creation and editing requires careful Riverpod provider scoping. If the form provider is not properly reset between navigation events, stale values from a previously edited type may pre-populate a new creation form, leading to incorrect data being saved.
Mitigation & Contingency
Mitigation: Scope the form state provider to the route using Riverpod's autoDispose modifier, ensuring the state is torn down when the screen is popped. Write a widget test that navigates to edit type A, pops, navigates to create new, and asserts all fields are empty.
Contingency: If provider scoping proves complex with the current router setup, fall back to separate widget implementations for create and edit that share a common form widget but maintain independent provider instances.
Archiving an activity type must not break historical Bufdir export queries that filter activities by type. If the export pipeline performs an INNER JOIN against only active activity types, archived types will cause historical activities to be silently excluded from exports, producing incorrect reporting data.
Mitigation & Contingency
Mitigation: Audit all downstream query builders (Bufdir export, stats aggregation) before shipping the archive feature to confirm they join against all activity types regardless of is_active status. Add an integration test that archives a type, then asserts historical activity records for that type still appear in export queries.
Contingency: If a downstream query is discovered to filter on is_active post-launch, apply a targeted Supabase view fix that unions active and archived types for export contexts without requiring a mobile app update.