Notification Settings
Feature Detail
Description
Notification Settings gives users granular control over which notification types they receive and via which channels. Users can enable or disable individual notification categories (assignments, activity reminders, event updates, expense status) and choose preferred delivery channels per category. Settings are persisted per user and synced to the backend so preferences survive device switches and app reinstalls. The settings screen is accessible from the app's hamburger menu.
Sources & reasoning
Blueprint marks notification-settings [MVP]. WCAG 2.2 AA (mandatory from day one per likeperson.md) and GDPR both require user control over notification delivery. Settings are foundational infrastructure that push-notifications depends on to respect user preferences, confirming MVP placement.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
User control over notification preferences is both a usability requirement and a GDPR compliance obligation. Peer mentors - many of whom are volunteers - must manage notification volume to avoid alert fatigue that could cause disengagement. For organizations serving users with disabilities (Blindeforbundet, NHF), granular settings allow tailoring to cognitive and sensory needs. Persisting preferences server-side ensures reinstalling the app or switching devices does not reset carefully configured notification state, reducing support overhead and improving long-term user satisfaction.
Implement a notification_settings table with per-user boolean flags for each notification category and channel preference. The Flutter settings screen uses grouped toggle switches with clear labels and WCAG 2.2 AA-compliant touch targets (minimum 24x24px). Settings are synced to the backend via a PATCH endpoint on each change and cached locally in Drift for offline reads. On first install, all push categories default to enabled and email/SMS channels default to disabled. Screen reader traversal order must be verified to be logical and all toggles must have accessible semantic labels.
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.