ContactService
Component Detail
Service Layer
medium complexity
mobile
0
Dependencies
0
Dependents
1
Entities
0
Integrations
Description
Business logic layer that enforces role-based contact visibility rules and translates tenant-specific Organisation Labels before handing data to the UI. Coordinates between ContactRepository and the role-based access control system to ensure peer mentors never receive contacts outside their scope.
contact-service
Sources & reasoning
Priority matrix (line 162) marks contact search MUST in Phase 1 across all four organizations. MVP scope narrative (line 320) lists contact list as Phase 1. Architecture section (line 291) confirms role-specific list views. Phase 1 in source docs maps to MVP by ordinal position (Fase 1 = first deliverable phase = MVP).
-
docs/source/likeperson.md · line 162Basic search (contact og notater) | ✓ | ✓ | ✓ | ✓ | ✓ | MUST | 1
-
docs/source/likeperson.md · line 320Kontaktliste og likepersonsoversikt
-
docs/source/likeperson.md · line 291Contacts list with role-specific views
Responsibilities
- Apply role-based filtering so peer mentors receive only their own contacts
- Inject tenant-specific Organisation Labels into contact records
- Orchestrate sync between remote API and local Drift database
- Expose reactive streams of contacts for real-time UI updates
- Handle search query delegation to ContactRepository
Interfaces
getContactsForUser(userId: string, role: UserRole): Stream<List<Contact>>
searchContacts(query: string, userId: string, role: UserRole): Stream<List<Contact>>
syncContacts(): Future<SyncResult>
resolveOrganisationLabel(tenantId: string, key: String): String