Contact List & Search
Feature Detail
Description
The contact list and search feature gives peer mentors and coordinators a paginated, role-filtered directory of all contacts under their purview. A dedicated search widget supports lookup by name and other identifiers, enabling rapid record retrieval during or after field interactions. Role-specific views ensure peer mentors see only their assigned contacts while coordinators see the full set for their local association, with display terminology driven by the active organisation's label configuration.
Sources & reasoning
Line 162 explicitly marks contact search as MUST HAVE Phase 1 for all five organisations. Line 291 confirms role-specific views as a core mobile architecture requirement. Line 467 canonically places this feature in the Contacts area taxonomy. MVP target derives from the Phase 1 position in the priority matrix and from line 321 listing contact list as a Phase 1 deliverable.
-
docs/source/likeperson.md · line 162| Basic search (contact og notater) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
-
docs/source/likeperson.md · line 291- Contacts list with role-specific views
-
docs/source/likeperson.md · line 467| contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin |
Analysis
Contacts are the core subject of every activity registration on the platform; without fast, reliable access to the right contact record, peer mentors face friction at every logging step, undermining the platform's primary goal of minimal cognitive load. Basic contact search was rated MUST HAVE, Phase 1 by all five organisations in the needs matrix. Coordinators also benefit from at-a-glance visibility into their full portfolio of contacts across local associations. The role-filtered design prevents accidental cross-contact data access, supporting GDPR compliance and organisational data separation requirements across multi-tenant deployments.
Implemented in Flutter using Riverpod state management with a paginated ContactListScreen backed by the Drift local database for offline-first access. The ContactSearchWidget debounces input and queries the local SQLite index first, falling back to the REST API for contacts not yet cached. Role filtering is enforced at both the API layer (organisation and user scoping) and mirrored in the local schema. The ContactService abstracts repository calls and applies the organisation labels system so that display terms (e.g. "Kontakt", "Familie") reflect the active tenant's configuration fetched from the backend at session start and cached offline for use without connectivity.
Components (11)
Shared Components
These components are reused across multiple features
User Stories
No user stories have been generated for this feature yet.