Service Layer medium complexity mobile
1
Dependencies
1
Dependents
1
Entities
0
Integrations

Description

Manages the Blindeforbundet-specific workflow for writing read-receipt confirmations back to Supabase when a coordinator accesses an encrypted contact field. Ensures audit trail compliance.

Feature: Contact Detail & Edit Screen

read-receipt-service

Summaries

The Read Receipt Service is a compliance-critical component that creates an auditable trail every time a coordinator accesses an encrypted contact field — a requirement specific to Blindeforbundet's data governance obligations. By automatically recording who accessed what sensitive data and when, the organization can demonstrate accountability to regulatory bodies and internal oversight without relying on manual logging processes. This reduces legal and reputational risk, supports data protection compliance, and gives leadership verifiable evidence of responsible data stewardship — a meaningful competitive differentiator for organizations handling sensitive member information.

This medium-complexity service carries compliance implications that elevate its delivery priority above its technical complexity would suggest. Any delay in implementing or testing this component risks deploying the encrypted field reveal feature without its mandatory audit trail — a compliance gap that could require emergency hotfixes post-launch. Its single dependency on `field-encryption-utils` is relatively contained, but end-to-end testing must include live Supabase writes to validate the audit record schema. Coordinate with Blindeforbundet's data protection officer early to confirm the exact fields that must be included in each receipt record.

Treat this component as a non-negotiable blocker for encrypted field access features going live.

This service writes directly to Supabase when encrypted fields are revealed, exposing three methods: `recordReadReceipt(String contactId, String fieldKey, String userId) -> Result`, `getReadReceiptStatus(String contactId, String fieldKey) -> ReadReceiptStatus`, and `listReadReceipts(String contactId) -> List`. The `recordReadReceipt` call must be atomic and include timestamp, user ID, and field key in the persisted record — consider wrapping the Supabase insert in a retry with exponential backoff to handle transient connectivity failures in mobile environments. The dependency on `field-encryption-utils` is used to validate that the field being accessed is indeed encrypted before writing a receipt. The `ReadReceiptStatus` and `ReadReceipt` types should be strongly typed against the `read-receipt` and `encrypted-field` data models.

Ensure RLS (Row Level Security) policies in Supabase restrict receipt writes to authenticated users only.

Responsibilities

  • Write read-receipt record to Supabase when encrypted field is revealed
  • Record timestamp, user ID, and field key in the receipt
  • Expose receipt status for UI feedback

Interfaces

recordReadReceipt(String contactId, String fieldKey, String userId) -> Result
getReadReceiptStatus(String contactId, String fieldKey) -> ReadReceiptStatus
listReadReceipts(String contactId) -> List<ReadReceipt>

Relationships

Dependencies (1)

Components this component depends on

Dependents (1)

Components that depend on this component

Related Data Entities (1)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/read-receipts 7 endpoints
GET /api/v1/read-receipts List all read receipts
GET /api/v1/read-receipts/:id Get read receipt by ID
POST /api/v1/read-receipts Record a read receipt (recordReadReceipt)
PUT /api/v1/read-receipts/:id Update a read receipt record
DELETE /api/v1/read-receipts/:id Delete a read receipt
GET /api/v1/read-receipts/status Get read receipt status for a contact field (getReadReceiptStatus)
+1 more