RBAC Meeting Notes
- Jenna Makowski
- Guillermo Viedma
Mar 31, 2025
Any last comments on the Systems Abstraction Doc?
Caution from Dave: The backend will be different from the product-facing side, but we should not be using the same definitions for frontend and backend things. Can have things on the backend that might link roles to resources, for example, and call it something different.
Review of project deliverables:
Phase 1
interviews and competitive research - DONE
To do - transfer to wiki
Phase 2
user stories for MVP - DONE
UX flows - DONE
Permissions mapping - partially done, needs to be picked back up
Next phase? Start with an audit of instructor dashboard permissions and full view of current state
Phase 3 - PRD
PRD needs more clean up, integration of feedback
Integrate competititve research into UX/UI requirements
Technical Requirement docs - DONE
Systems Abstraction
Mar 10, 2025
Libraries permissions definitions
Decision: Will not add audit library role to keep roles simpler
Are custom roles something we can achieve on the MVP?
No, too technically complex for an MVP
architecture that will enable custom roles, with a minmial user facing delivery (set library roles)
Where will the UX/UI for the MVP live?
For the MVP, keep it scoped to just the library level.
For platform level configurations - design sprint to help answer questions about global configs
Django will stay regardless - will be the system level backstop
At a data layer, django will display lookups, will also be easier to debug
Administrating at a system level is going to exist regardless as the global view. How does tihs affect the priotization
Everything in django admin comes for free when we implement a feature and developers need that
Next steps - start writing user stories and basic UX flows at the library level
Need some basic principles for the UX flows at the global level
Next step - start a shared community doc with big hairy open questions about global configurations
Do the rbac high level ux flows at the same time
Where are these permissions going to live?
xkcd standards: Technical Approach: Roles and Permissions
Mar 3, 2025
Key Discussion Points:
System Abstractions Document:
No additional questions raised on last week's updates.
The document has been shared with the EDUNEXT team for further review.
Library Permissions & Roles:
Permissions for the library feature have been mapped out.
Proposed roles:
Library Administrator – Full control over library content.
Library Author – Can read and add content.
Library Auditor – Read-only access (discussion on whether this role is necessary).
Library User – Can use libraries when creating courses.
Permission Granularity:
Debate on whether to split certain permissions for clarity (e.g., edit a library encompassing multiple actions).
Agreement that permissions should be meaningful without unnecessary complexity.
Potential for more detailed permissions in the future but keeping them broad for the MVP.
Scopes & Exceptions:
Discussion on whether to allow exclusions for certain courses within an organization (e.g., grant access to 93 out of 100 courses without manually adding each one).
The MVP will not include this level of granularity but may be considered later.
User Interface for RBAC MVP:
Unclear if the implementation will be in Django admin, LMS, Studio, or a new UI.
Decision pending further discussion with the team (notably @Jenna Makowski ).
Next Steps:
First iteration of user stories will be developed this week.
Further discussions will be held on permissions needing refinement.
Clarification is needed on the UI implementation.
2025-02-24
Refining definitions/abstractions
Modified terminology: “Domains” now “Resource Types”
Resources are concrete instances, e.g. individual Course Runs. While “Resource Type” is the abstract concept of “Course Run”.
Eg: Resource type = course; Resource = Introduction to Pedagogical Method
Permissions are defined in relation to Resource Types. Scopes specify how to select Resources.
Esteban: Suggest that we do a preliminary review of all the Resource Types we have in platform.
Jenna agrees. We want to land on a fairly finite number of them.
Mahnoor: Resource Types would be mapped to permissions?
Yes.
Dave: Scope questions:
Do scopes have names?
Do we have pre-canned named scopes?
Scopes in general still need some fine-grained details
How will scopes handle exceptions? (possibly not in scope for MVP)
Guillermo: If we punt on scope exceptions from MVP, can we add exceptions in later?
Dave: Do we need custom scopes for MVP?
Current state of scopes: Have ability to assign:
permission to an individual course or library, and
assign a role for all courses in an org and
all courses globally
Custom Scopes are probably not in scope for MVP
MVP is Custom Roles but not Custom Scopes
Guillermo: Can courses have permission to libraries, or is it based only on users?
Esteban: Simpler to restrict them to staff.
Dave and Jenna agree
Jenna: Nuanced question: We have Library Viewer, Author, Admin. What about the permission to reuse content? Is this also a new library role? Or a permission added to course roles?
If someone is a Course Author, do they have a Library role to be able to read from content libraries?
Example of Library Viewer: Auditing the content, but not be able to edit it.
Dave/Guillermo/Jenna - Probably (maybe?) need a fourth library role for Library user to be able to reuse content in a course
This allows us to keep all new role definition within libraries
Mahnoor - alternative approach is make “reuse library content” as a permission to course roles
Dave - there may be a way to add the reuse content permission without having to tackle the whole course role at once
Mahnoor: Past experience, platform had a central system to add permissions to all the different systems
Multi-org/multi-tenancy
MVP definition/UX prototypes
Mahnoor demo
Jenna
Feedback: User story is “I would like to see all the current users who have roles in this library” -- view space would be helpful.
Within the library, it makes sense to assign roles to that library from within that library. But does the higher level permissions assignment layer happen here (e.g. creating custom roles, assigning to many libraries) or somewhere else?
Two use cases:
1. In context adding to a specific library
2. I want to manage users across many libraries for admin purposes.
Esteban: In-context is okay, centralized is okay. If we cannot have both, we can have a link that sends you to a centralized thing from the individual library.
2025-02-18
Project-level design:
Term definition
Team preference to have approach conversations async
Next steps: Auslasneo to put forth next round of approach proposals within the next 2 days, so everyone can begin discussions/refinement async
Multi-org vs multi-site
Multi-org sites will have specific needs
Wanting to rename roles
Custom roles
Desire to assign/customize roles at org level without having to go to admin
Also need to define custom roles at the platform level
May not need for MVP, but need to model for it
Multi-site sites
Need to understand specific needs (edunext as key stakeholder) but may be easier to design without this as the primary case, and focus instead of developing such that multi-tenancy needs can be built on top of it/extended from it
Next steps: Need to do interviews with edunext (re: multi-site) and set up a few new interviews to understand multi-org (2U, possibly WGU or ASU)
MVP Design: Libraries
Beginning to build understanding of use cases