Role Assignment
Feature Detail
Description
Allows organization administrators to assign, change, and revoke roles for users within their organization. Roles determine which product surfaces a user accesses - Mobile App for peer mentors and coordinators, Admin Web Portal for org admins - and which data operations they may perform. The feature enforces multi-tenant isolation so admins can only assign roles within their own organization, and prevents privilege escalation beyond the assigning admin's own role level.
Sources & reasoning
Role assignment is inseparable from user management in a multi-role, multi-tenant platform. The source explicitly defines four roles with distinct access surfaces and states that org admins manage role membership. The Fase 1 MVP roadmap includes rolletildeling (role assignment) as a named MVP deliverable alongside user invite and deactivation.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Correct role assignment is the control plane for the platform's entire access model. Without it a peer mentor could inadvertently gain coordinator-level access or a former coordinator could retain privileges after an organizational change. The four organizations have distinct delegation rules - coordinators dispatch assignments, org admins approve expenses and run reports, global admins have cross-org visibility - so role semantics must be clear and changes immediately reversible. The feature is an explicit MVP requirement listed alongside user management in the Admin Web Portal scope for all four organizations.
Role data is stored in the user_organization_roles junction table linking users to organizations with a role enum. The REST API enforces that only an org admin or global admin may modify roles within the org, and rejects any attempt to grant a role exceeding the requesting admin's own scope. Role changes take effect within one token refresh cycle - no forced logout is required but the new role is evaluated on the next API call. The UI presents each role with a plain-language description of its access boundaries before the admin confirms, preventing accidental privilege escalation.
Components (45)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.