Role Access Validator
Component Detail
Description
Validates and scopes statistics access based on user role. Coordinators may only see their own peer mentors via Supabase RLS; org admins see all coordinators within their org. Prevents unauthorized cross-coordinator data access at the service layer as a defence-in-depth measure.
role-access-validator
Summaries
The Role Access Validator is the mobile application's defence-in-depth access control layer for statistics data. While Supabase Row-Level Security enforces access restrictions at the database level, this component provides an additional safeguard at the service layer — ensuring that a coordinator can never accidentally query another coordinator's peer mentor data, and that org admins are correctly scoped to their own organization. This dual-layer protection reduces the risk of data breaches or privacy violations, which is especially critical in a peer mentoring context involving sensitive participation and reimbursement data. Shared across statistics features, it ensures consistent access enforcement without duplicating logic, reducing compliance risk and simplifying audits.
Role Access Validator is a low-complexity shared component with no external dependencies, making it one of the lower-risk deliverables in the statistics feature set. Because it is shared across multiple statistics features, it should be prioritized early in the development sequence so that dependent service components (coordinator stats service, personal stats service) can integrate it from the start rather than retrofitting access checks later. Testing requirements include role-based unit tests covering coordinator-scoped access, org-admin access, and unauthorized access rejection. Since this component enforces security policy, it must go through security review before the statistics features ship.
No deployment blockers anticipated — it is a pure Dart/Flutter service layer component with no network calls of its own.
Role Access Validator is a shared mobile service with no external dependencies. It exposes three members: validateStatsAccess (async check returning a StatsAccessScope for a given requesting user / target coordinator pair), getAccessScopeForCurrentUser (convenience method for the logged-in session), and the StatsAccessScope value object (level enum + orgId + optional coordinatorId). The StatsAccessLevel enum should cover at minimum: COORDINATOR_SCOPED and ORG_WIDE. Downstream consumers (coordinator-stats-service, personal-stats-service) should call getAccessScopeForCurrentUser() and pass the resulting scope to stats-repository query methods, so the repository can apply the correct filter without re-checking roles.
This layered approach keeps role logic centralized here and query logic in the repository. User-role data model drives the access determination.
Responsibilities
- Check that requesting user may access statistics for the given coordinatorId
- Determine correct query scope (coordinator-scoped vs org-wide)
- Return normalized scope object consumed by stats repository queries
Interfaces
validateStatsAccess(String requestingUserId, String targetCoordinatorId) → Future<StatsAccessScope>
getAccessScopeForCurrentUser() → Future<StatsAccessScope>
StatsAccessScope({required StatsAccessLevel level, required String orgId, String? coordinatorId})