Event Listing
Feature Detail
Description
Event Listing displays upcoming and past events relevant to the logged-in user within their organisation. The screen is role-aware: peer mentors see events they are eligible to join, while coordinators see all events in their local association. Events are fetched from the REST API with organisation-scoped filtering and cached locally in Drift for offline access. The listing serves as the central navigation hub for the Event Management area, linking each item to a detail view and the sign-up flow. Basic filtering allows users to locate specific events without scrolling through long lists in high-volume organisations.
Sources & reasoning
Event listing is the natural complement to event creation and is marked [MVP] in the blueprint. The source doc confirms role-specific screen variants throughout the mobile app; the event listing must apply the same pattern. Without this screen no user can discover events, making it a structural dependency for the entire Event Management area and for all downstream participation tracking.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Without a discoverable event listing, peer mentors cannot find and join group activities and coordinators cannot monitor upcoming commitments - rendering event creation invisible to end users. Participation data depends entirely on users being able to locate events, making this screen a hard prerequisite for accurate Bufdir reporting. For coordinators managing tens to hundreds of peer mentors, a clear event list replaces manual communication via phone or email. Reducing that overhead frees coordinator time for higher-value activities such as mentoring quality and follow-up, which are the outcomes Bufdir-funded programmes are formally evaluated on.
Implemented as a paginated Flutter screen using Riverpod, fetching events from GET /api/v1/events with server-side organisation scoping derived from the JWT. Drift caches event records locally so the list remains usable offline. Role-based display logic runs client-side from the user's role claim without an extra API call. The screen reuses platform list and card widgets for visual consistency with the contact and activity screens. Each list item requires an accessible combined label (event name plus date) for screen reader navigation. Load-more pagination handles high-volume organisations without UI freezing or memory pressure.
Components (44)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.