/
RBAC Meeting Notes

RBAC Meeting Notes

Sep 4, 2025

Technical discussion: Technologies Comparison

 

Aug 21, 2025

UI overview:

  • Presented figma files at UX/UI working group

  • Key feedback:

    • Probably a better decision from the UI pov to limit the scope of the panel view to just the library in scope for the MVP. Implications for UI:

      • Remove scope filters

      • Remove Applies to column

      • Simplify as much as possible

    • Keep “Team Members” as opposed to “Users”

    • Keep the permissions icons

    • Future refinements:

      • Some personas may not need to see all staff on a library like support staff, etc

DECISION: Do we limit the views of the console to just the library in scope for Ulmo, or allow users t remove the scope filter and see a platform-view of all libraries?

*We will limit the views to just the library in scope

Backend architecture design

 

 

Aug 14, 2025

Pending decision:

Will the MVP of the console be limited to just the view and editing actions of that particular library? See: https://www.figma.com/design/q3Knq0BKoVTBbtaxb81n9R?node-id=2272-11586#1383818229

@Guillermo Viedma to compile a pro/con analysis and a place to compile edge cases that require further scoping

Eg - If I enter the Console view from Library 1, and I am only an author on Library 1 and have no roles in other libraries, and if I remove the library scope filter from the console, am I able to see users who have roles in both Library 1 and other Libraries where I am not a team member?

 

Jul 31, 2025

To Do:

  • @Guillermo Viedma PRD for console:

    • Move the PRD outside RBAC

    • Split the longterm PRD and the MVP

  • Review the dates for the deliverables of RBAC SOW, to help define what enters Ulmo cut @Maria Grimaldi @Diana Catalina Olarte

  • Share possible backup plans in case we don’t have enough time to build the Console UI for Ulmo @Guillermo Viedma

Jul 21, 2025

To do:

Open questions:

  • What is feasible for inclusion in Ulmo?

 

 

 

Jun 9, 2025

  • Guillermo made progress in setting up the GitHub project.

  • We talked about the Console SOW - https://docs.google.com/document/d/1QsocjLf167cuTRI5AGtklrR0TfsMJI4KzX3XaPPeIs4/edit?usp=sharing

    • There are a few comments, but nothing is blocking the proposal.

    • We should have two PRDs: one for the RBAC MVP, which is already in the wiki, and one for Console. We already have data about the Console; the idea would be to gather it.

    • And see if we can have the architecture and UX/UI design spike simultaneously to help each other.

  • Regarding the second SOW, which is about roles and permissions, Edunext will send it at the beginning of this week.

    • Part of the work will involve establishing the Roles and Permissions Foundation - Architecture Design Spike. To guide the implementation of roles and permissions, we have created a requirement file. We would like you to review it and help us identify the required and optional features. https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5030805509


Jun 2, 2025

Things to be reviewed:

May 19, 2025

SOWS in progress:

  1. Technical implementation - still open questions on the approach https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4777607193/Technical+Approach+Roles+and+Permissions?focusedCommentId=5001740303

    1. Next steps to evaluate:

      1. If we ran an external service for centralized authorization, what’s the lift and setup?

      2. How much ram, does it need bridgekeeper/other extra services, etc?

      3. How big are they in terms of overhead (for developers, for operators)?

      4. How mature is their documentation?

      5. Can we avoid hacky passing of tokens between studio, lms, django, external services like Aspects

      6. What’s the synchronization process between the LMS and Studio? eg, making/granting permissions in Studio and then using them in the LMS

      7. How to handle queries based on authorization?

    2. Next steps - try out locally in a playground

    3. Then PoCs later, with a more refined list based on findings above

  2. Product updates

    1. What repo should tickets for this project go in?

      1. Decision - we should create a new repo

        1. Name - openedx-authz

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?

 

Mar 3, 2025

Key Discussion Points:

  1. System Abstractions Document:

    • No additional questions raised on last week's updates.

    • The document has been shared with the EDUNEXT team for further review.

  2. 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.

  3. 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.

  4. 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.

  5. 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 ).

  6. 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

  •