🏠 Overview › ✅ Implementation Tasks ›✅ epic-organization-selection-service-labels-task-007

Implement label key resolver and fallback logic

epic-organization-selection-service-labels-task-007 — Implement the label resolution logic in OrgLabelsProvider: given a LabelKey, return the organization-specific string if defined, otherwise fall back to the default Norwegian term. Ensure missing keys never throw — return the key name as a debug fallback. Add a getLabelOrDefault helper method consumed by the TerminologyAwareTextWidget.

high priority low complexity backend pending backend specialist Tier 4

Acceptance Criteria

getLabelOrDefault(LabelKey key) returns the org-specific override string when one is defined for the active org
getLabelOrDefault(LabelKey key) returns the default Norwegian term when no org-specific override is defined
getLabelOrDefault(LabelKey key) never throws under any circumstances — missing keys return the key's name as a debug string (e.g., '[MISSING: peerMentor]')
The debug fallback string is only returned in debug/profile builds; in release builds it returns the default Norwegian term
All four org label maps have been verified to cover the full LabelKey enum — a compile-time or startup assertion flags missing entries
getLabelOrDefault is a synchronous method — it does not require async even though the underlying map is loaded asynchronously
TerminologyAwareTextWidget correctly calls getLabelOrDefault and displays the resolved string
Unit tests cover: org override found, org override missing (falls back to default), key absent from default map (debug fallback), all four orgs return a non-null value for every LabelKey

Technical Requirements

frameworks
Flutter
Riverpod
data models
LabelKey (enum)
OrgLabelMap (Map<LabelKey, String>)
DefaultNorwegianLabels (const Map<LabelKey, String>)
performance requirements
getLabelOrDefault must be O(1) — pure map lookup, no iteration
security requirements
Debug fallback strings must not expose internal system information beyond the label key name
ui components
TerminologyAwareTextWidget — consumes getLabelOrDefault

Execution Context

Execution Tier
Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

Implementation Notes

Implement getLabelOrDefault as a method on OrgLabelsProvider (or as a standalone extension/utility class that takes the loaded map as input). The resolution chain is: (1) check org override map, (2) check default Norwegian map, (3) return debug fallback. Use Dart's ?? null-coalescing for concise implementation: `return _orgMap[key] ??

_defaultMap[key] ?? _debugFallback(key)`. Define `const Map kDefaultNorwegianLabels` as a compile-time constant — this ensures zero runtime cost and makes coverage of missing keys easy to assert at startup. Consider adding a debug-mode assertion in OrgLabelsProvider.build() that iterates all LabelKey values and logs any that are missing from the loaded org map — this catches gaps early during development without affecting release performance.

Testing Requirements

Pure unit tests using flutter_test — no mocking of external dependencies needed. Test cases: (1) org override returned when present, (2) Norwegian default returned when org has no override for a key, (3) debug fallback '[MISSING: keyName]' returned in debug mode when key is absent from both maps, (4) method never throws for any input including null-coerced edge cases, (5) all LabelKey enum values resolve to a non-null string for each of the four partner orgs. Run exhaustive parameterized tests across all enum values × all orgs.

Component
Organization Labels Provider
infrastructure low
Dependencies (1)
Implement OrgLabelsProvider to fetch organization-specific label mappings from Supabase (or bundled config) for the selected organization. Expose labels as a Riverpod AsyncNotifier so UI widgets reactively rebuild when the active organization changes. Support all four partner organizations: NHF, Blindeforbundet, HLF, Barnekreftforeningen — each with their own terminology overrides. epic-organization-selection-service-labels-task-005
Epic Risks (2)
high impact medium prob technical

The OrgLabelsProvider must be fully initialized before any UI widget renders organization-specific text. If the service triggers label initialization asynchronously and the UI builds before the labels stream emits, widgets will briefly display raw label keys instead of human-readable text, which constitutes a WCAG 2.2 AA failure for screen readers that announce whatever text is present at render time.

Mitigation & Contingency

Mitigation: Design the OrgSelectionService.select() method to await OrgLabelsProvider initialization before completing its Future — callers receive a resolved future only after labels are ready. Use an AsyncValue loading state to gate UI rendering via Riverpod's when() pattern.

Contingency: If awaiting initialization causes perceivable UI lag, implement an optimistic render with a skeleton loading state that is announced by the live-region-announcer as 'Loading organization content' so screen readers do not announce raw keys.

medium impact medium prob integration

If the label definitions loaded from the backend for each organization do not match the label key registry used in the UI, widgets will fall back to raw keys silently. This is particularly harmful for Blindeforbundet users relying on VoiceOver, where a raw key announced by a screen reader is incomprehensible.

Mitigation & Contingency

Mitigation: Define a compile-time label key registry (enum or const strings) and assert at OrgLabelsProvider initialization that all required keys are present in the loaded map. Log a structured warning for any missing key and substitute a human-readable fallback string rather than the raw key.

Contingency: If a label schema mismatch reaches production, the OrgLabelsProvider fallback mechanism ensures users see a reasonable English default rather than a raw key. A backend label patch can be deployed without an app release.

Quick Links
All Tasks Execution Plan