Role Assignment
Feature Detail
Description
Role Assignment allows administrators to assign and change the roles of users within an organization. The four defined roles - Peer Mentor, Coordinator, Organization Admin, and Global Admin - carry distinct access boundaries across the mobile app and admin portal. This feature provides the UI widget and API surface for modifying a user's role, with appropriate guards to prevent privilege escalation beyond the acting admin's own role level. The feature also manages the `user_roles` table which stores role-to-user mappings and is the authoritative source for authorization decisions across the platform. Role changes take effect on the next token refresh, ensuring sessions are not abruptly invalidated mid-use.
Analysis
Role assignment is the enforcement point for the platform's access model. Without it, coordinators cannot be distinguished from peer mentors, and org admins cannot be distinguished from global admins, making the entire authorization layer non-functional. Incorrect role assignments directly affect what data users can see and what actions they can perform, including expense approvals, user invitations, and Bufdir report generation. The constraint that admins cannot assign roles above their own level is a security requirement - it prevents privilege escalation attacks where a compromised org admin account could create global admins. This also supports the principle that Norse Digital Products (global admins) retains control over cross-organization access without requiring application-level code changes per organization.
The role assignment widget is a dropdown or segmented control rendered inline on the user detail page. The available role options are filtered server-side based on the acting admin's own role - org admins see only Peer Mentor, Coordinator, and Org Admin; global admins see all four. The assignment is persisted to the `user_roles` table via a PATCH to `/api/v1/admin/users/:id/role`. Role changes do not immediately invalidate existing access tokens; they take effect on the next refresh cycle (typically within 15 minutes given the short-lived token design). If immediate revocation is needed (e.g., disciplinary action), that is handled by the Session Revocation feature in the Security & Audit area. Role history is written to `audit_logs` for compliance traceability.
Components (41)
Shared Components
These components are reused across multiple features
User Interface (9)
Service Layer (15)
Data Layer (8)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.