Event Creation
Feature Detail
Description
Event Creation allows coordinators and peer mentors to schedule events through a guided multi-step wizard covering title, date, time, duration, location, and summary. The wizard mirrors the activity registration pattern to minimise cognitive load for users already familiar with the app. Events are persisted to the shared backend with organisation scoping, feed directly into the event listing and sign-up flows, and are togglable per tenant via module configuration. Offline creation is supported through the Drift mutation outbox, ensuring coordinators working in low-connectivity environments can schedule events without interruption.
Sources & reasoning
The event wizard is explicitly listed in the Mobile App Architecture screens section confirming MVP scope. The blueprint marks event-creation as [MVP]. Events feed Bufdir reporting - a MUST HAVE for all four organisations - making event creation foundational. The multi-step wizard pattern is directly cited in the source doc alongside the activity wizard, establishing parity.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Events are a core coordination mechanism across all four client organisations - workshops, group meetings, and support sessions require documentation for Bufdir grant reporting. A structured wizard ensures all required metadata (title, date, time, duration, location) is captured consistently, eliminating reliance on ad-hoc tools such as email or spreadsheets. For coordinators managing large peer mentor teams, frictionless event creation reduces administrative overhead and produces audit-ready records. Accurate event data strengthens funding applications, validates impact claims, and feeds directly into the organisational statistics available to Org Admins in the Admin Web Portal.
Implemented in Flutter as a multi-step wizard with BLoC/Riverpod managing step state across back-navigation to prevent data loss. The Event Service posts to REST API endpoint POST /api/v1/events with organisation context derived from the JWT, persisting to the events table. Offline events are queued in the Drift mutation outbox and synced on reconnect using the existing retry/backoff mechanism. Shared form widgets from the activity wizard are reused for visual and interaction consistency. WCAG 2.2 AA requires semantic field labels, minimum 24×24 CSS pixel touch targets, and visible focus indicators on all wizard controls throughout.
Components (46)
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.