Integration test ContactRepository against RLS policies
epic-contact-list-management-foundation-task-008 — Write integration tests for ContactRepository that verify end-to-end behavior: coordinator role sees only contacts within their organization_id, peer_mentor role cannot access contacts outside their assigned chapter, fetchBySearch returns only matching records within scope, and that no cross-organization data leaks occur. Use a test Supabase instance or local shadow database with seeded multi-org data.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Implementation Notes
Set up a test/integration/ directory separate from unit tests. Use supabase_flutter's SupabaseClient initialized with the test project URL and anon key from environment variables. To impersonate roles in tests, use supabase.auth.signInWithPassword() with pre-seeded test users for each role, or use the admin API to create short-lived test JWTs. Commit seed SQL to supabase/seed.sql so CI can run supabase db reset to get a clean state.
Add a Makefile or CI step (e.g., GitHub Actions) that runs supabase start, supabase db reset, then flutter test integration_test/. Document that these tests require the Supabase CLI and Docker to be available in CI.
Testing Requirements
Integration tests using flutter_test with a real Supabase connection. Structure: setUp() creates authenticated Supabase client for a given role using test JWT or service role key to impersonate users; tearDown() signs out and clears session. Group tests by scenario: (a) coordinator scope isolation, (b) peer_mentor chapter isolation, (c) search scope correctness, (d) cross-org data leak prevention. Use expect(result.every((c) => c.organizationId == expectedOrgId), isTrue) assertions.
Consider adding a negative test using the Supabase service role key to confirm data exists in DB but is blocked by RLS for the test user.
Existing Supabase RLS policies for the contacts and peer_mentors tables may not align with the application-level UserRole model, causing ContactRLSQueryBuilder to construct filter expressions that are redundant, conflicting, or that allow over-fetching. In a multi-chapter context (NHF), this could expose contacts belonging to other chapters.
Mitigation & Contingency
Mitigation: Audit and document the existing RLS policies against the UserRole enum before writing a single line of query builder code. Write integration tests asserting cross-organization data isolation using separate test user tokens for each role.
Contingency: If RLS policies are misaligned at runtime, add an explicit application-level organization_id equality check in ContactRepository as a secondary guard while the database policies are corrected in a coordinated migration.
The Supabase schema for contacts and peer_mentors tables may differ from the expected typed models — missing columns, renamed fields, or type mismatches — causing deserialization failures that surface only at runtime during integration testing.
Mitigation & Contingency
Mitigation: Document expected schema fields upfront and validate against the live Supabase schema at sprint start. Use freezed and json_serializable for compile-time-safe deserialization with explicit required/optional field declarations.
Contingency: Introduce nullable fields with safe defaults for any schema mismatches discovered in testing; log deserialization errors to the monitoring service so schema drift is caught before production deployment.