Select Activity Type from Organisation-Labelled List
Each organisation uses different terminology for activity types (e.g. 'Home Visit', 'Phone Conversation', 'Group Session'). The activity type selection step must load the list from the organisation-specific activity type repository and apply the organisation labels provider so the displayed names match what the coordinator and peer mentor expect. The list should be short (5–10 items) and ordered by frequency of use for that mentor. Inactive or admin-only types must be hidden. The selected type persists as the new default for the next registration.
User Story
Audience Summaries
Accurate activity type categorisation is a hard requirement for Bufdir grant compliance — mislabelled activities cannot be allocated to the correct funding category, resulting in rejected reports or costly manual rework by coordinators. Each partner organisation uses its own terminology, and exposing generic system codes to peer mentors creates confusion and systematic miscategorisation. By loading organisation-specific labels directly from the administrator-configured repository, this story eliminates a major source of data quality error without requiring any peer mentor training. The frequency-ordered list and persistent default further reduce cognitive load per registration, compounding the data quality improvements delivered by the two-tap flow.
Cleaner data means faster coordinator review cycles, higher confidence in Bufdir submissions, and reduced administrative overhead across all three organisations.
This story has a direct dependency on story 733 (quick registration flow) and must be scheduled immediately after it. Delivery complexity is moderate: the activity type list must be fetched from an organisation-specific repository, filtered to remove inactive and admin-only types, and sorted by per-mentor usage frequency — requiring both backend query logic and client-side caching for offline support. Stakeholder coordination is needed with each organisation's administrator to confirm their activity type taxonomy and ensure the admin tooling for managing types is already in place or planned. Acceptance criteria include offline cache display with a staleness indicator, which requires a cache invalidation strategy and UI design input.
Testing must cover multi-organisation scenarios (an HLF mentor must never see RIO or LHL types), inactive type filtering, and offline degraded-mode behaviour. Rollout should be coordinated with the activity type administrator setup for each organisation.
The activity type list is sourced from an organisation-specific repository, meaning the fetch must be scoped by the authenticated user's organisation ID. The list endpoint should return typed objects including a display label, a system ID, an active flag, and a usage count for the current mentor. Client-side, inactive types must be filtered before rendering, and the list sorted by descending usage count with the top 5 surfaced above a visual divider. The selected type ID must be persisted to the registration preferences store as the new default, making it available to the bottom sheet component on the next open.
Offline support requires caching the last-fetched list (e.g. in AsyncStorage keyed by organisation ID) and displaying a subtle staleness badge when the device is offline. Edge cases include an empty list after filtering (show a fallback message), a first-time user with zero usage history (show alphabetical order), and an admin deactivating a type that is the current user default (clear the default and prompt re-selection on next open). Integration tests should validate cross-organisation isolation.
Acceptance Criteria
- Given I belong to organisation HLF, when I open the activity type selection step, then I see activity type names exactly as defined by the HLF administrator, not generic codes
- Given the activity type list is loaded, when the list contains more than 8 items, then the most recently used 5 types appear at the top separated by a divider from the full list
- Given I select an activity type, when I proceed to the next step, then the selected type is stored in the registration preferences store as my new default
- Given an activity type has been marked inactive by an admin, when I open the activity type step, then that type does not appear in my selection list
- Given I am offline, when I open the activity type step, then the cached list of activity types is shown and a subtle indicator communicates that the list may not reflect the latest admin changes
Business Value
Correct activity type categorisation is mandatory for Bufdir grant reporting. Mislabelled activities cannot be counted in the correct funding category, leading to rejected reports or manual rework by coordinators. Organisation-specific terminology reduces cognitive load and errors, directly improving data quality without requiring training.
Components
- Activity Type Selection Step ui
- Activity Type Selection Screen ui
- Activity Type Service service
- Activity Type Metadata Resolver service
- Activity Type Repository data
- Activity Type Cache Provider data
- Supabase Client infrastructure
- Organization Labels Provider infrastructure
- Registration Defaults Manager service
- Registration Preferences Store data