HIGH story-role-based-access-control-peer-mentor-006 8 pts
8
Story Points
High
Priority
Role-Based Access Control
Feature

User Story

As a Peer Mentor (Likeperson)
I want my coordinator permissions to be correctly scoped to the specific chapter or organizational unit I am responsible for
So that I cannot view or modify data belonging to other chapters I do not administer, ensuring data privacy across the organization hierarchy

Audience Summaries

This story directly protects the organization's legal standing and member trust by enforcing strict data isolation between chapters in large federated structures like NHF, which spans 12 national associations, 9 regions, and 1,400 local chapters. Coordinators handle sensitive personal data including health status and encrypted assignment records. Without scoped role resolution, cross-chapter data leakage would constitute a GDPR violation, exposing the organization to regulatory fines, reputational damage, and potential loss of trust agreements with partner organizations. Delivering this capability is a prerequisite for any production deployment, making it a strategic blocker with direct legal and contractual obligations attached.

This is a high-priority, high-complexity story with cross-cutting impact across the entire data access layer. It depends on two upstream stories (story-role-based-access-control-coordinator-001 and -004) and must be delivered before any coordinator-facing feature can be considered production-ready. Implementation involves configuring Supabase Row Level Security policies, building the role repository, and wiring the permission checker into all data queries. UAT must include edge cases such as multi-chapter coordinators, mid-session assignment changes, and the NHF-specific duplicate detection cross-chapter query requirement.

A dedicated QA cycle focusing on security boundary testing is essential before this story can be signed off.

Implementation requires configuring Supabase RLS policies on all coordinator-accessible tables (contacts, activity logs, peer mentor rosters) scoped by org-unit assignments stored in the role repository. The permission checker service must validate org-unit scope before any query execution. Multi-chapter coordinators need a session-level active chapter context selector with all downstream queries parameterized by that selection. The duplicate detection edge case for NHF requires a controlled cross-chapter query that reads all chapters a coordinator manages without leaking data from unrelated coordinators — this likely requires a server-side function or RPC with elevated privileges scoped by verified assignment.

Session refresh logic must trigger role re-resolution to reflect backend assignment changes.

Acceptance Criteria

  • Given a coordinator is assigned to Chapter A, When they load the contacts list, Then only contacts associated with Chapter A are returned
  • Given a coordinator attempts to access a peer mentor from Chapter B via a direct URL, When the data query executes, Then Supabase RLS policies return no data and the screen shows an appropriate empty state
  • Given a coordinator is assigned to multiple chapters, When they select their active chapter context, Then data and actions are scoped to the selected chapter only
  • Given a coordinator's chapter assignment changes in the backend, When they next open the app or refresh their session, Then their scoped data view updates to reflect the new assignment
  • Given duplicate activity detection runs across chapters (NHF requirement), When the system checks for duplicates, Then it queries across all chapters a coordinator manages without exposing other coordinators' chapter data

Business Value

Data isolation between organizational chapters is a hard requirement given the sensitive personal information (health status, contact details, encrypted assignment data) stored in the system. Without proper org-scoped role resolution, a coordinator could inadvertently access or modify another chapter's member data, violating GDPR and the organizations' trust agreements.