Add encrypted field metadata queries to contact repository
epic-contact-detail-and-edit-foundation-task-004 — Extend contact-detail-repository to query encrypted field metadata: which fields are encrypted for a given contact, their encryption key references, and read-receipt timestamps. Return encrypted field stubs alongside plaintext fields so the UI layer can request decryption separately without blocking initial load.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Store encrypted field metadata in a separate table (e.g., contact_encrypted_field_meta) with columns: contact_id, field_name, key_reference, key_version, read_at. Join this table in the existing contact query using PostgREST embedded resource syntax. For the read-receipt update, use Supabase RPC (a database function) that accepts contact_id and field_name and sets read_at = now() — this guarantees server-side timestamping and avoids a client update with a user-controlled timestamp. Keep EncryptedFieldStub immutable (use Dart's @immutable annotation); the decryption layer creates a new DecryptedField object rather than mutating the stub.
This clean separation prevents accidental logging of decrypted data.
Testing Requirements
Unit tests: (1) getContactById returns ContactDetailRecord with a non-empty encryptedFieldStubs list when the contact has encrypted fields; (2) getEncryptedFieldsForContact returns only the stub list without full contact data; (3) recordFieldReadReceipt calls the correct Supabase update with server-timestamp instruction; (4) encrypted blob columns are absent from all query SELECT lists (assert on the query string or mock call arguments). Integration test: verify that a coordinator cannot read encrypted field metadata for a contact outside their organisation. Verify read-receipt timestamp is set to the server time after calling recordFieldReadReceipt.
Blindeforbundet's encryption key retrieval mechanism may not be finalised at implementation time, or session key availability via Supabase RLS may be inconsistent, causing decryption failures that expose masked placeholders to users and degrade the experience.
Mitigation & Contingency
Mitigation: Agree with Blindeforbundet on key storage and retrieval contract before implementation starts. Prototype key retrieval in a spike against the staging Supabase instance and validate the full decrypt/verify cycle with real test data before committing to the implementation.
Contingency: Implement a fallback that shows a 'field temporarily unavailable' state with a retry affordance. Log decryption failures server-side for audit. Escalate to Blindeforbundet stakeholders to unblock key management before the service tier epic begins.
NHF contacts may belong to up to 5 chapters, each governed by separate RLS policies. A coordinator's chapter scope may not cover all affiliations, causing partial profile reads or silent data omissions that are difficult to detect in tests.
Mitigation & Contingency
Mitigation: Map all RLS policy combinations for multi-chapter contacts early. Write integration tests that create contacts with 5 affiliations and query them from coordinators with varying chapter scopes. Use Supabase's RLS test utilities to verify row visibility per role.
Contingency: Add an explicit 'affiliation partially visible' state in the repository response model so the UI can communicate scope limitations to the coordinator rather than silently showing incomplete data.
Organisation-specific validation rules (e.g., NHF chapter limit, Blindeforbundet encrypted field edit flow) may expand in scope during implementation as edge cases are discovered, causing the validator to grow beyond the planned complexity.
Mitigation & Contingency
Mitigation: Define the complete validation rule set with product and org stakeholders before coding begins. Document each rule with its source organisation and acceptance test. Use a rule registry pattern so new rules can be added without modifying core validator logic.
Contingency: Timebox validator enhancements to 2 hours per additional rule. Defer non-blocking rules to a follow-on maintenance task rather than blocking the epic delivery.