Implement location privacy configuration loader
epic-geographic-peer-mentor-map-consent-privacy-task-002 — Build the location-privacy-config infrastructure component that loads and exposes per-organisation privacy policy URLs, consent dialog copy, data retention periods, and applicable GDPR lawful basis settings. Configuration must be readable at runtime without app rebuild, sourced from Supabase organisation settings table, and cached locally with TTL.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Implement as a Riverpod `AsyncNotifier
For the Supabase query, use a `.select()` call filtered by `organisation_id` matching the current session's org claim — avoid fetching all organisations' configs. Model the GDPR lawful basis as a Dart enum `GdprLawfulBasis { consent, legitimateInterest, legalObligation }` with a `fromString` factory for JSON deserialization. This component will be consumed by the consent dialog UI (downstream task) and by the LocationConsentService, so keep the API surface minimal and focused on read-only access.
Testing Requirements
Unit tests using flutter_test and mocktail. Test cases: (1) First call fetches from Supabase mock and caches result — verify Supabase client called exactly once; (2) Second call within TTL returns cached result — verify Supabase client NOT called again; (3) Call after TTL expiry re-fetches — verify Supabase client called again; (4) Supabase error on fetch — verify fallback default config returned and no exception thrown; (5) refresh() call invalidates cache and triggers re-fetch; (6) privacyPolicyUrl with HTTP scheme is rejected and replaced with fallback URL; (7) Riverpod provider emits AsyncLoading, then AsyncData with correct config. Use `FakeAsync` from `fake_async` package to simulate TTL expiry without real time delays in tests.
If the privacy policy text or consent terms change after mentors have already opted in, existing consent records may become legally insufficient, requiring re-consent from all opted-in mentors which could temporarily reduce map coverage.
Mitigation & Contingency
Mitigation: Store a consent_version field on every consent record. Implement a consent version check in location-consent-service that compares the stored version against the current policy version from location-privacy-config and flags stale consents for re-consent prompting.
Contingency: If a policy update invalidates existing consents, suppress affected mentors from the map, queue them for re-consent notification via the existing in-app notification system, and restore map visibility only after new consent is recorded.
A poorly designed consent dialog may lead to low opt-in rates, reducing map utility for coordinators to the point where the feature delivers insufficient value to justify maintenance cost.
Mitigation & Contingency
Mitigation: Follow plain-language writing guidelines from the cognitive accessibility feature. User-test the dialog with 2-3 peer mentors from Blindeforbundet before implementation is finalised. Ensure the dialog explains the benefit to the mentor, not just the data collection facts.
Contingency: If opt-in rate after launch is below 40%, conduct a targeted usability study and iterate on dialog copy and layout. The coordinator can also send a bulk opt-in invitation notification (per the user story) to non-consenting mentors.