Org receipt threshold config data model and repository
epic-receipt-capture-and-attachment-foundation-task-011 — Define the OrgReceiptThresholdConfig data model containing the receipt_required_threshold_nok field (default 100 NOK). Implement a read method in or alongside ReceiptThresholdValidator that loads the org-specific threshold from Supabase org configuration. Ensure the config is cached locally to support offline threshold checks.
Acceptance Criteria
Technical Requirements
Implementation Notes
Store the threshold in the existing org settings table if one exists, or create a lightweight org_receipt_config table with columns: org_id (FK), receipt_required_threshold_nok (numeric, default 100). For local caching, use SharedPreferences with key 'receipt_threshold_{orgId}' and a timestamp key 'receipt_threshold_{orgId}_fetched_at'. On app resume, check if fetched_at is older than 1 hour and trigger a background refresh. Expose the config via a Riverpod AsyncNotifierProvider
The validator itself should be a pure function taking the threshold and amount as parameters — dependency on the config should be at the caller level, not inside the validator, to keep it testable.
Testing Requirements
Unit tests using flutter_test with mockito. Scenarios: (1) Supabase returns a row → OrgReceiptThresholdConfig constructed with correct threshold, (2) Supabase returns empty list → default 100.0 NOK returned, (3) cached value returned on second call without Supabase being called again (verify mock not called twice), (4) isReceiptRequired(99.99) returns false, isReceiptRequired(100.0) returns true, isReceiptRequired(150.0) returns true, (5) offline scenario: local cache returns last-known value when Supabase throws SocketException. Integration test (optional): verify against test Supabase project that RLS prevents cross-org threshold access.
Supabase Storage RLS policies using org/user/claim path scoping may not enforce correctly if claim ownership is not present in the JWT or if path segments are constructed differently at upload vs. read time, leading to data leakage or access denial for legitimate users.
Mitigation & Contingency
Mitigation: Define and test RLS policies in isolation before wiring to app code. Write integration tests that assert cross-org and cross-user access is denied. Use service-role key only in edge functions, never in client code.
Contingency: If client-side RLS proves insufficient, route all storage reads through a Supabase Edge Function that validates ownership before generating signed URLs, adding a controlled server-side enforcement layer.
Aggressive image compression may reduce receipt legibility below the threshold required for financial auditing, causing claim rejections or compliance failures despite technically successful uploads.
Mitigation & Contingency
Mitigation: Define minimum legibility requirements with HLF finance team before implementation. Set compression targets conservatively (e.g., max 1MB, min 80% JPEG quality) and validate with sample receipt images. Provide compression statistics in verbose/debug mode.
Contingency: If post-compression quality is disputed by auditors, increase the quality floor at the cost of larger file sizes, and add a manual override allowing users to skip compression for PDFs and high-quality scans.
The Flutter image_picker package behaves differently on iOS 17+ (PHPicker) vs older Android (Intent-based), particularly for file types, permission flows, and PDF selection, which may cause platform-specific failures not caught in development.
Mitigation & Contingency
Mitigation: Test image picker integration on physical devices for both platforms early in the sprint. Pin the image_picker package version and review changelogs before updates. Write widget tests using mock file results for each platform branch.
Contingency: If PHPicker or Android Intent differences cause blocking issues, implement separate platform-specific picker delegates behind the unified interface, allowing platform-specific fixes without breaking the shared API.