Event Sign-up
Feature Detail
Description
Event Sign-up allows peer mentors and coordinators to register themselves or their contacts as participants in an event directly from the Event Detail Screen. The sign-up widget captures the participant's identity, confirms availability, and writes a record to the Event Participants Table, providing real-time participant counts visible to organizers. Coordinators can also remove participants or register on behalf of contacts who lack app access, supporting the proxy registration pattern required by NHF and HLF.
Analysis
Participant tracking is a hard requirement for Bufdir reporting - organizations must demonstrate how many individuals were reached by each activity. Manual attendance collection via paper lists or email introduces transcription errors and delays that have historically led to undercounting and funding risk. Embedding sign-up directly in the event flow creates a real-time participant record that feeds automatically into reporting, eliminating a costly reconciliation step. For coordinators, the ability to register contacts and proxy-sign-up non-app users means the system covers the full participant population, not just the subset with smartphones, which is essential for organizations whose members include elderly and low-digital-skill users.
The sign-up widget is a small stateful BLoC component embedded in the Event Detail Screen that calls a POST endpoint on the event participants resource. The backend validates that the requesting user belongs to the same organization as the event before writing to the Event Participants Table, preventing cross-tenant registration. For coordinator proxy sign-ups, the endpoint accepts an optional contact_id parameter; the mobile app surfaces a contact picker scoped to the coordinator's organization. Optimistic UI updates the participant count immediately while the request is in flight, with rollback on failure matching the pattern used by contact edits. Offline sign-ups are queued in the mutation outbox and synced when connectivity is restored, with conflict detection to prevent duplicate participant records on the backend.
Components (42)
Shared Components
These components are reused across multiple features
User Interface (9)
Service Layer (15)
Data Layer (8)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.