PRD Roles & Permissions
- Jenna Makowski
- Guillermo Viedma
[NOTE: THIS IS A LIVING DOCUMENT. We will continue to make changes every time a new consensus emerges. The goal of this document is to create a clear understanding of the topic and track all the discussions we have around the definition of the product]
Overview
The Roles and Permissions (RBAC) improvement project aims to enhance how permissions are managed on the Open edX platform. This initiative focuses on simplifying role assignments, enabling custom roles, and improving user experience for platform administrators and course teams. By addressing existing pain points, the project seeks to make role management more efficient, scalable, and aligned with organizational needs.
Background
Open edX is a learning platform used by millions of users around the globe. The types of organizations that rely on it are highly diverse, and the current RBAC system is inflexible, causing many users to struggle with adapting their needs to the limited set of existing roles.
The Axim team selected Aulasneo, an Open edX partner, to assess user satisfaction with the current system and propose a modern RBAC solution that fulfills the needs of all Open edX users.
Problems
The current roles and permissions system in Open edX platform is inefficient for organizations offering multiple courses and requiring global permissions across the platform. Repetitive tasks, such as manually adding or removing staff members for each course during staff changes, create unnecessary workloads.
Additionally, the platform lacks granular permissions, resulting in over-permissioned users, which risks data security and inefficiency.
Role administration is further complicated by requiring users to navigate multiple areas—LMS, Studio, and the Django admin console—to manage roles and permissions effectively.
Objectives
Centralize Administration Interface: Offer a single point where users can view role assignments and the scope of each role.
Streamline User Experience: Simplify the role management interface and workflows for administrators and instructors.
Improve Efficiency: Introduce bulk role assignment and user-friendly tools to reduce repetitive tasks.
Default Roles: Provide out-of-the-box roles to fulfill the needs of most users in the default installation.
Enhance Flexibility: Allow custom roles with specific permissions to meet diverse organizational needs.
Permission Grouping: Make the permissions list human-readable, grouping them in a way that helps administrators do their job effectively.
Hierarchy Definition: Enable the definition of roles at different levels—platform-wide and within smaller contexts such as courses or cohorts.
Constraints WIP
Cross-platform Impact: The project affects all the screens in the platform, things like enrollments are entwined with what a user can see or do. Making changes in permissions could affect other user flows.
Compatibility: Ensure changes are backward-compatible with the current system to avoid disruptions.
Incremental upgrade: The solution is going to be so big that upgrading the whole system at the same time is impossible, we need a way to make small changes that gradually replace the whole system.
User Personas
Platform admin
Course Designer
Course Instructor
Instructor Assistant
Course Auditor
Learner
WIP
A list of the personas built using the information gathered from user interviews and the open survey is presented in this document. Here is also included a list of personas based on the current roles of the platforms, imagined from the permission set they have right now.
The exercise would help to propose a new set of default roles available out of the box.
Also illustrates how the current base set (and based on our research, any set) isn’t enough to fulfill the requirements of all the different organization that uses edX Platform, highlighting the needs of custom roles.
Key features
Permission Set: A comprehensive list of all permissions in the platform and tools to manage/search them.
Custom Roles: Define roles with specific permissions tailored to organizational needs.
Role Hierarchy: Associate roles with specific contexts (platform, organization, course, cohort, section).
Assign Roles: Assign permissions to users by linking them to roles.
User Administration: List all roles assigned to a user across all hierarchy levels.
Context Administration: View all users and their roles within a specific context.
Default Roles: Provide predefined roles to meet most organizational needs.
RBAC Administration UI: A centralized view where users can see their status and manage roles and permissions (if authorized).
MVP TBD
Detailed Specs (WIP)
User Flow
System Abstractions
This document outlines the core abstractions for the new Role-Based Access Control (RBAC) system. These abstractions are intended to facilitate discussion and guide the architectural design process. They are not final definitions but serve as a foundation for collaboration
System Abstraction Diagram:
Base Roles Permission Set
Permission mapping: WIP
A list of all permissions available in the platform:
Base set: WIP
A set of permissions describing the 6 new roles proposed as the new base role set, and the legacy roles that already exist in the platform
User Personas Permission mapping
User Stories
TBD
Benchmarking
Five platforms were selected for analysis to identify common practices and industry standards in role-based access control (RBAC). The goal is to establish a benchmark that Open edX can aim for in developing a robust and flexible RBAC system tailored to its unique needs.
Risks
Two RBAC Systems Operating Simultaneously: Gradual upgrades may require the coexistence of old and new RBAC systems, which could increase complexity.
Impact on Other Features: Changes may affect workflows like “enroll” actions, and may require decoupling permissions from enrollment status.
Authentication Constraints: Integration with the current authentication system must be seamless. If it lacks flexibility, it may limit the new solution.
Open questions
Is the current hierarchy sufficient?
Will we provide an API for this feature?
What default roles should be included?
Where will the new RBAC section be accessed from?
What is the best way to list all permissions?
Should course content be accessible without enrollment?
Can we have two RBAC systems active simultaneously?
What library will be used to develop the solution?
Can we build on the current authentication system?
Do we migrate the current roles?
Agreements
The first iteration will be developed over Django Admin
Admin role will inherit the permissions from the Data Researcher
Course Staff will inherit permissions from the Data Researcher under that context
We need to connect the models provided by Django with an assessment over the front end
Permissions/Policies will have a scale that helps the administrator create awareness when granting permissions to sensitive areas.
Permissions will have an explanation
Designs
TBD
Success Metrics
TBD
Technical assessment WIP
Resources
User Interviews
Open Survey
Research
Benchmarking
List of all permissions in the platform
Rollout plan
TBD