No-Access Screen for Restricted Roles
Feature Detail
Description
A dedicated screen shown when a user's role does not have access to the mobile application — specifically global administrators whose work is done through the web-based admin portal rather than the mobile app. The screen must clearly communicate why access is restricted and where the user should go instead. This screen prevents confusion for users who accidentally attempt to use the mobile app with a global admin account, maintaining a clean separation between the mobile peer mentor experience and the administrative back-office.
Analysis
Prevents support burden from global admins attempting to use the wrong interface, and maintains a clear product boundary between the mobile app and the admin portal.
Rendered as a terminal route when role check fails for mobile access. Should display org logo, a clear explanation message, and a link or instruction pointing to the admin portal URL. Logout button must be present.
Components (201)
Shared Components
These components are reused across multiple features
User Interface (59)
Service Layer (52)
Data Layer (33)
Infrastructure (54)
User Stories (6)
As a As a Organization Administrator
I want to tap a link on the no-access screen that opens the organization's coordinator contact page or support resource in an external browser
So that I can request elevated access or find help without leaving the app manually or searching for contact information
- Given the no-access config repository has an external URL configured for the blocked route, when the no-access screen is rendered, then a labelled external link button is displayed below the denial explanation
- Given the peer mentor taps the external link, when the url launcher utility processes the request, then the URL opens in the device's default browser or mail client
- Given the url launcher fails to open the URL, when the error is caught, then a plain-language fallback message (e.g., 'Could not open link — please contact your coordinator directly') is shown
- +2 more
As a As a Organization Administrator
I want to see a brief, plain-language explanation on the no-access screen that tells me specifically why I cannot access a feature
So that I can take appropriate action — such as contacting my coordinator — instead of feeling confused or frustrated
- Given a peer mentor is redirected to the no-access screen from a coordinator-only route, when the screen renders, then a route-specific denial message is displayed rather than a generic fallback
- Given the no-access config repository contains a support contact URL for the blocked feature, when the no-access screen renders, then a clearly labelled 'Contact Support' or 'Contact Coordinator' button is visible
- Given the denial message is displayed, when it is evaluated against cognitive accessibility criteria, then it uses short sentences, avoids technical jargon, and follows the plain-language content service guidelines
- +2 more
As a As a Organization Administrator
I want to see a role switch option on the no-access screen when I have another role that would grant me access
So that I can switch to the appropriate role and continue my task without logging out and back in
- Given a peer mentor who also holds a coordinator role attempts to access a coordinator-only route, when the no-access screen is shown, then a role switch widget offering the coordinator role is displayed
- Given the role switch widget is displayed and the peer mentor selects the coordinator role, when the role state manager updates the active role, then the user is navigated to the originally requested route without re-authentication
- Given a peer mentor has only one role and lacks permission for the blocked route, when the no-access screen renders, then no role switch option is shown
- +2 more
As a As a Organization Administrator
I want to have a clearly labelled back button or 'Go to Home' action on the no-access screen
So that I can return to an area I am permitted to use without needing to close and reopen the app
- Given a peer mentor is on the no-access screen, when they tap the back button, then they are navigated to the previous accessible screen without app state loss
- Given a peer mentor is on the no-access screen and there is no safe previous route, when they tap 'Go to Home', then they are navigated to the role-based home screen
- Given the no-access screen is displayed, when the peer mentor inspects the UI, then a persistent back button is visible in the header rather than relying on swipe-to-dismiss gestures
- +2 more
As a As a Organization Administrator
I want to see a clear, informative no-access screen when I attempt to navigate to a section I do not have permission to use
So that I immediately understand that the area is restricted and I have not made a mistake or encountered a technical error
- Given a peer mentor is authenticated and navigates to a coordinator-only route, when the role route guard evaluates permissions, then the no-access screen is displayed instead of the target route
- Given the no-access screen is displayed, when the peer mentor views the screen, then a headline such as 'Access Restricted' and a plain-language explanation of the restriction is visible
- Given the app uses organization-specific terminology, when the no-access screen renders, then labels are resolved through the organization labels provider so wording matches the org's configured terminology
- +2 more
As a As a Organization Administrator
I want the no-access screen to be fully navigable with a screen reader and to display with sufficient contrast and scalable text
So that I can understand the access restriction and my options even if I use assistive technology or have low vision
- Given a VoiceOver user lands on the no-access screen, when the screen appears, then the live region announcer triggers an announcement of the denial headline without requiring manual navigation
- Given a screen-reader user navigates through the no-access screen, when they traverse all focusable elements, then the heading, explanation text, and all action buttons are announced in logical order with appropriate roles
- Given the no-access screen is displayed, when it is evaluated against WCAG 2.2 AA contrast requirements, then all text elements meet a minimum 4.5:1 contrast ratio against the background
- +2 more