[Draft] Optimize discussion forum roles and permissions
Background
There are 4 forum roles in Open edX and various course roles. Forum moderation privileges are distributed among these roles as shown in the table below.
Opportunity
Forum roles and permissions in Open edX at present are somewhat redundant and likely misaligned with real course operations because:
The roles most responsible for managing course discussions, namely Course Staff and Course Admin, lack moderation privileges. Their only exception is the ability to pin and bulk delete.
There are 4 forum roles that share almost identical permissions, with the exception of cross-cohort visibility and bulk-delete access.
This may create confusion for course teams.
For example, an instructor reported being unable to pin posts and assumed this was a bug. Extending pin/unpin permissions to Course Staff and Course Admin temporarily addressed this but increased inconsistency in how forum permissions are distributed.
Goals
Enable course owners (staff and admins) to moderate their own forums without needing extra roles.
Simplify the discussion role structure to make it easier to understand, manage, and document.
Proposed way forward
Grant ALL forum moderation privileges to Course Staff and Course Admin roles.
Deprecate the Discussion Admin and Discussion Moderator roles, which duplicate permissions already available in other roles. Retain TA and Group TA roles for cases where moderation privileges must be granted to users who are not on the course team (e.g., learners).
Role | Proposal |
|---|---|
Course Staff | Grant ALL forum moderation privileges |
Course Admin | Grant ALL forum moderation privileges |
Discussion Admin | Deprecate |
Discussion Moderator | Deprecate |
TA | Unchanged |
Group TA | Unchanged (maybe deprecate, see below) |
Potential optimization: Deprecate Group Community TA role
The Group Community TA role exists to support courses that divide their learners into cohorts, allowing a TA to moderate only within their assigned group.
Usage data from a large Open edX instance over the past 1 year shows that fewer than 1% of courses had this role enabled, with only 5 users assigned this role among hundreds of thousands of active users. Maintaining a separate role for such a limited use case increases documentation, configuration, and testing overhead without providing proportional value.
Deprecating this role and relying on the TA role instead would simplify permissions while maintaining essential moderation capabilities. The only trade-off is that TAs would gain visibility into discussions across all cohorts, rather than being restricted to one.
Comments
Thanks so much, both Aamir and Guillermo. Very glad to see this moving forward. Couple of thoughts, particularly around how we might parallelize the product requirement process for Studio roles and Discussion roles at the same time:
I think we want to avoid, if we can, having the Studio roles working with both the legacy and new AuthZ at the same time. Rather, we want to be moving as quickly as possible toward applying the new AuthZ framework to all roles--new, old and improved.
In terms of timeline, Guillermo is currently working on defining requirements for improved out-of-the-box Studio roles, and what permissions those roles should have. We are aiming to have those drafted by the end of November. At the same time, Aamir, I think it would be productive for you to do the same for the Discussion roles. Rather than starting with incremental improvements, what are the end-state Discussion roles we need and what permissions do they need? If you could do that definition and mapping on a similar timeline, then we can sync on those two sets of roles (Studio roles and Discussion roles) - and align the specs where we need to (ie, which Discussions permissions do we also need to include with the broader Studio roles). That gives us two centralized, coordinated product requirements.
Once we have those requirements, then we can do two things. 1.) I think we should have a group workshopping/design session on implementing the next phase of the admin console, with key stakeholders. 2) We can finalize technical input on how to phase the implementation of both sets of roles – studio and discussion.
Sound like a path forward?
Great to see us adding muscle to extend AuthZ
Visualizing the end state helps, since iterating on these sections takes months, and we won’t get to a complete system without taking big steps. We can always negotiate smaller scopes later.
This looks like the right path. Anything @aamir ayub needs to help him ramp up faster, I’m available.
Sounds good to me. @Guillermo Viedma do you have a template/guide document that i can follow to think through this?
It’s great to start seeing some discovery around AuthZ.
As quick feedback, I’ll share a few areas we need to expand, based on the last AuthZ MVP, to tackle some of the problems you analyzed here:
First and most important, we need to reach parity in the new AuthZ before expanding current features. This means:
Create the permissions you already listed, and analyze whether there is a benefit in splitting some of their current behavior.
Define and create the new roles that hold those permissions.
Define and create the scopes affected by those permissions, for example, a forum, all forums, all forums related to an org.
Define the interface to grant or revoke those roles using the new dashboard, and decide whether the current UI remains or not.
Expand the scopes logic to include forums, courses, and re-runs, and analyze how scopes interact with each other.
Analyze whether Course Admin and Course Staff will be fully migrated to the new AuthZ by the time this is implemented, and if not, how we can support a hybrid approach where those roles work using both legacy and new AuthZ. This is probably the hardest thing to align. During the MVP, we worked on creating new roles to reduce the responsibilities of broader roles. The pattern so far focused on parity and splitting permissions to allow more flexibility, here the approach is to expand an already broad role. Do not get me wrong, I think the current situation is confusing, and the most logical thing is to add those permissions to those roles, but we are leaning towards making AuthZ more flexible and not more centralized in a few roles, allowing the user to decide if they want to grant broader or limited roles based on their needs.
You can read how we tackled some of these things in the MVP, and also some technical definitions of roles, permissions, scopes, and their implementation. Feel free to ask me, or other members of that team, anything you don't understand in the documentation.
PD: I would love to see more usage data related to roles if you can share.