Contact Detail Service
Component Detail
Description
BLoC/Riverpod-managed service that orchestrates fetching of a contact's full profile, activity history, and assignment status from the repository layer. Resolves organization-specific data requirements such as multi-chapter affiliations and encrypted field presence.
contact-detail-service
Summaries
The Contact Detail Service is the central orchestration layer that assembles everything a coordinator needs to know about a Blindeforbundet contact in a single, coherent view. By resolving multi-chapter affiliations, assignment status, activity history, and encrypted field requirements in one place, this service eliminates the need for coordinators to manually cross-reference multiple data sources. The result is faster, more confident decision-making by staff, reduced risk of acting on incomplete information, and a secure handling path for sensitive contact data — directly supporting organizational compliance and member trust.
This medium-complexity service is a critical dependency for both the contact detail screen and several downstream features, including activity history display and assignment status rendering. Its two repository dependencies — `contact-detail-repository` and `assignment-repository` — must be available and contract-stable before integration testing can begin. The encrypted field detection logic introduces a layer of complexity that requires sign-off from Blindeforbundet's data governance team on which fields are encrypted and under what organizational configurations. Delays in clarifying these requirements are the primary scheduling risk.
Budget time for integration testing across all four data models it touches: contact, activity, assignment, and chapter.
Implemented using BLoC or Riverpod for reactive state management, this service exposes five core methods: `getContactById`, `getActivityHistory`, `getAssignmentStatus`, `getChapterAffiliations`, and `requiresEncryptedDisplay`. It coordinates calls to `contact-detail-repository` and `assignment-repository`, composing their responses into a unified state object for the UI layer. The `requiresEncryptedDisplay(String fieldKey) -> bool` method consults organization-specific configuration to determine field sensitivity — this logic should be isolated and unit-tested independently. State emissions should distinguish between loading, loaded, and error states.
Multi-chapter affiliation resolution may involve fan-out repository calls; consider parallelizing with `Future.wait` for performance.
Responsibilities
- Fetch and expose full contact profile data to the UI layer
- Retrieve activity history associated with the contact
- Resolve assignment status for Blindeforbundet contexts
- Determine which fields require encrypted display based on organization config
Interfaces
getContactById(String contactId) -> Contact
getActivityHistory(String contactId) -> List<Activity>
getAssignmentStatus(String contactId) -> AssignmentStatus
getChapterAffiliations(String contactId) -> List<Chapter>
requiresEncryptedDisplay(String fieldKey) -> bool
Relationships
Dependencies (2)
Components this component depends on
Dependents (2)
Components that depend on this component
Related Data Entities (4)
Data entities managed by this component