Route-Level Access Enforcement for Coordinator Screens
Every protected route in the application is guarded by a role route guard that checks the current resolved role against the route's permitted roles before rendering. If a coordinator attempts to navigate to an admin-only screen (e.g., global admin dashboard), the guard intercepts the navigation and redirects to the no-access screen with a contextual explanation. The no-access route guard specifically handles denial flows, and the access denial service provides the reason string and optional contact action rendered by the no-access screen widget.
User Story
Audience Summaries
Route-level access enforcement is a foundational security requirement that directly protects organizational data integrity and user confidentiality across all pilot organizations. By ensuring coordinators cannot access admin-only screens such as global user management or billing dashboards, the application upholds strict role boundaries that organizations depend on to maintain compliance and operational trust. This story eliminates a category of unauthorized data exposure risk that could otherwise undermine adoption by organizations handling sensitive participant information. Given that all three pilot organizations identified this as a MUST HAVE requirement, delivering it cleanly is directly tied to pilot success, customer retention, and the credibility of the platform as an enterprise-grade solution.
Strong access controls also reduce support burden and liability exposure, representing both a cost-saving and risk-mitigation investment.
This critical-priority story requires coordinated delivery across the routing layer, role resolution services, and the no-access screen widget. The implementation depends on story-role-based-access-control-coordinator-001 being complete, making sequencing essential. Acceptance criteria are well-defined and testable: guard behavior for blocked and permitted routes, custom versus generic denial messages, and contextual UI on the no-access screen. QA must cover both happy-path navigation and denial edge cases for each role pairing.
Stakeholder sign-off is required from at least one pilot organization to validate the denial message UX. Rollout risk is low if the role route guard is implemented as a centralized, reusable widget, but fragmented guard implementations across individual routes would introduce regression risk during future screen additions. Delivery timeline is tightly coupled to the access control foundation story.
Implementation requires a role route guard component that intercepts GoRouter navigation events, resolves the current user role from the role state manager, and compares it against a per-route permitted roles configuration. Denied navigations must redirect to the no-access route, passing route context metadata so the no-access screen can display a contextual explanation sourced from the no-access config repository. The access denial service must expose a reason string and optional contact action consumed by the no-access screen widget. Edge cases include unauthenticated users hitting protected routes, role resolution latency causing guard evaluation on stale state, and custom versus fallback message logic in the config repository.
Unit tests must cover guard allow/deny logic and redirect behavior. Integration tests must verify the full navigation interception flow including custom message rendering.
Acceptance Criteria
- Given a coordinator is authenticated, When they attempt to navigate to a route permitted only for admins, Then they are redirected to the no-access screen
- Given a coordinator is on the no-access screen, When it renders, Then it displays a human-readable explanation and an option to contact support or switch roles
- Given a coordinator navigates to a route they are permitted to access, When the route guard evaluates, Then navigation proceeds without interruption
- Given the no-access config repository has a custom message for the blocked route, When the no-access screen renders, Then it displays that custom message rather than a generic one
Business Value
Preventing role boundary violations protects data integrity and user confidentiality. Coordinators must not access admin-level user management or billing screens, and peer mentors must not reach coordinator bulk registration flows. Robust route guarding is a MUST HAVE for all organizations in the pilot.
Components
- Role-Based Route Guard infrastructure
- No-Access Route Guard service
- No-Access Screen ui
- No-Access Screen ui
- Access Denial Service service
- No-Access Configuration Repository data
- URL Launcher Utility infrastructure