/
PRD AuthZ for Course Authoring

PRD AuthZ for Course Authoring

v0.3 (draft) - THE SCOPE AND REQUIREMENTS ARE WIP shared for early feedback

1. Context and goals

1.1 Why authoring is next

With the Ulmo release we introduced a new AuthZ service for Libraries v2, with explicit roles, permissions and scopes. This gives us a more flexible foundation for access control on the platform.

Authoring in Studio is the natural next step. It is:

  • One of the highest impact areas for platform administrators.

  • A clear extension of the work already done for Libraries v2 and the Administrative Console.

  • A critical part of moving towards full AuthZ coverage across Open edX Platform.

The goals of the AuthZ work remain the same, now applied to authoring:

  • Centralize how roles and permissions are defined, stored and enforced.

  • Make roles more explicit so users can see what each role can and cannot do.

  • Reduce repetitive work when assigning roles and permissions across different areas of the platform.

  • Increase permission granularity so we can define more focused roles without granting unnecessary access.

1.2 Current pain points in Studio

Today, Studio authoring access is driven by a small set of broad roles (Admin, Staff, Limited Staff, Data Researcher) combined with LMS behavior.

Key issues:

  • Broad roles, limited control. It is hard for admins to support patterns like:

    • Edit content but not course settings.

    • Edit content but not publish.

    • Edit content but no Instructor dashboard access.

  • Fragmented assignment. Roles are assigned from multiple entry points (LMS Instructor Dashboard, Studio, Django admin), with different patterns per feature.

  • Limited bulk and cross-scope operations. Assigning roles to the same person across many courses is repetitive and error prone.

  • Weak visibility. It is difficult to answer “who has what access where” across Studio 

The result is a system that works, but is hard to delegate safely and costly to operate when there are many courses and teams

2. Scope of this iteration

This iteration focuses on extending the new AuthZ foundation from Libraries into Course authoring, without changing LMS behavior in the short term. If we can we would like to cover as much of Studio as possible, Authoring being the main focus.

In scope:

  • Use the shared AuthZ service and Administrative Console as the control plane for Studio authoring roles.

  • Define and pilot authoring-focused roles for Studio (for example, a Designer-style role).

  • Provide better tools to assign and review roles for authoring across multiple Scopes.

  • Keep Admin, Staff, Limited Staff as the entry point into authoring for this iteration.

Out of scope for this iteration:

  • Changes to LMS grading, cohorts, groups or discussion forums.

  • Deep refactors to enrollment.

3. Design principles WIP

  • Reuse the shared AuthZ service. Roles, permissions and scopes for authoring should live in the same system used by Libraries and the Administrative Console.

  • Explicit roles, clear descriptions. When an admin assigns a role, they should understand what that role enables and what it does not.

  • Scope aware. Permissions are always tied to a clear scope (for example, “this course”, “all courses in this org”, “this library”).

  • Reduce repetitive work. Admins should not have to repeat the same assignment dozens of times if the intent is clearly “this person has the same role on all these resources”.

  • Observe before expanding. Start with a small set of well understood authoring roles and expand based on usage and feedback.

4. Product Research

The Moodle and Canvas benchmarks surfaced several patterns that are relevant for Open edX authoring.

4.1 Structural patterns we want to bring in

  • Make authoring roles more explicit, with clearer boundaries between:

    • Course team management

    • Course content editing

    • Course settings

      • Grading

      • Schedule & Details

      • Certificates

      • Advance Settings

    • Course Misc. (Course Updates, Group Configuration)

    • Page and Resources management

    • Tool access?

  • Use a delegation model so we can express:

    • Which roles are allowed to assign or revoke other roles.

    • Which roles can change roles on which scopes.

  • Provide better “who has what where” views, including:

    • Local team members on a course or library.

    • “Other users” that have access via higher level scopes (global admin, org admin).

  • Support cross-scope operations where it makes sense, for example:

    • Assigning the same role to a user across multiple courses or libraries.

    • Viewing a user’s roles across many scopes in one place.

4.2 Early Discovery (Moodle/Canvas + User interviews)

Patterns we want to carry over:

  • Separation of authoring and grading.

    • Moodle: Teacher vs Non-editing teacher.

    • Canvas: Teacher / TA vs Designer.

    • Open edX AuthZ: introduce a content-focused role that can edit content but cannot grade and does not see detailed learner data.

  • Designer-style roles.

    • Canvas Designer can build content and structure, with no grading and limited settings.

    • This matches feedback we already received about needing a role that edits content without learner data access. This includes restricting access to Instructor Dashboard sections, for example Student Admin, and to data download features.

  • Delegated administration.

    • Moodle Manager and Canvas Sub-account Admin show how to distribute administration without full superuser rights.

    • For Open edX AuthZ, this connects to org-level or tenant-level roles that can manage teams across many courses and libraries.

  • “Other users” pattern.

    • Moodle lists users who have access via higher contexts under “Other users”.

    • Open edX AuthZ could adopt a similar pattern so course and library admins can see who else has access, even if they are not explicitly on the local team.

4.3 Community evidence for the two new authoring roles (Auditor, Course Editor)

Across interviews and Discuss threads, we consistently see demand for safer delegation in Studio, including (1) view only access for reviewers, and (2) content editing access without learner data, grading, and in some cases without publishing.

Auditor (view only, including draft content)
Interviews:

Discuss:

Content Editor (edit content without learner data or grading, limited settings)
Interviews:

Discuss:

Publishing is under discussion:
The “lock courses” request explicitly separates editing from publishing. WGU mentioned something similar, we need to open this discussion to the community to understand better what should be the default for a Course Editor.
We should keep this as a priority in technical discovery.

5. High level requirements for this iteration

This section summarizes what we want to enable in the next iteration so the technical team can size and slice the work.

5.1 Role model and permissions

  • R1.1 Use the shared AuthZ service to define Studio authoring roles, permissions and scopes, reusing the same model as Libraries v2.

  • R1.2 Model the existing course roles in the new system and provide parity over authoring capabilities.

  • R1.3 Introduce a content focused role for Studio that:

    • Can edit course content (pages, units, components). files?

    • Cannot grade and cannot access learners' data.

    • Has limited access to high impact settings (schedule and details, certificates, advanced settings).

  • R1.4 Introduce an auditor/view only authoring role that:

    • Can see all course content, including unpublished content.

    • Cannot edit content or change course settings.

    • Cannot grade and cannot access learners' data.

  • R1.5 Build granular permissions and validation points aligned with the functional areas listed in 4.1.

5.2 Scopes and delegation

  • R2.1 Support higher level scopes that can cover many resources in one assignment, for example:

    • All courses in the platform.

    • All libraries in the platform.

    • All courses in organization X.

    • All libraries in organization X.

  • R2.2 Split role management in AuthZ in:

    • Assign roles on a given scope.

    • Revoke roles on a given scope.

  • R2.3 Allow platform administrators to define constraints on revocation for sensitive roles, for example:

    • Roles that can only be revoked by users who also hold a specific admin role on the same or a higher scope.

    • Roles that grant access to many scopes that should not be removed by local course level users.

5.3 Assignment flows and bulk operations

  • R3.1 Reduce repetitive work for administrators when assigning authoring roles by supporting:

    • Assigning a role to several users in one flow for a given scope.

    • Assigning a role to a user across several scopes when there is a clear structural relationship (for example, all courses in an organization, all libraries in an organization).

  • R3.2 Route new assignment flows through the Administrative Console where possible, instead of adding more scattered entry points.

  • R3.3 Ensure operations are auditable:

    • Record who performed the change, when, and on which scopes.

5.4 Visibility: “who has what and where”

  • R4.1 For each course or library scope, provide a view that:

    • Lists local team members and their roles.

    • Shows “other users with access” via higher level scopes (for example, global admin, org admin, global staff) in a separate section, similar to the Moodle “Other users” pattern.

  • R4.2 Provide a user centered view that answers:

    • Which roles this user has on which courses and libraries.

    • Whether the access comes from a local assignment or from a higher level scope.

5.5 Cross cutting requirements

  • R5.1 Define a migration path from legacy course team roles into the new AuthZ model for Studio and Libraries, including:

    • Default mappings from Admin, Staff, Limited Staff and Course Data Researcher into new roles and scopes.

    • How to handle cases where a legacy role has no direct equivalent.

    • How to roll out new roles without breaking existing courses and library teams.

  • R5.2 Ensure new UI and flows related to authoring roles in the Administrative Console meet baseline accessibility expectations, including:

    • Keyboard navigation and focus management.

    • Clear labels and descriptions for roles, scopes and actions.

    • Structures that make scope and delegation understandable for assistive technologies.

5.6 Administrative Console requirements

  • R6.1 Reuse the existing Administrative Console patterns and components for role management, extending them from Libraries to Courses, including:

    • Using the current team table patterns (members, roles, actions) as the baseline.

    • Reusing the existing add member and change role interaction patterns where possible.

  • R6.2 Provide in context entry points from Studio into the Administrative Console for a specific course, including:

    • A deep link that opens the correct course context in the Console.

    • Clear identification of the course being managed.

    • A clear back path to Studio.

  • R6.3 Provide a general entry point from Studio into the Administrative Console that is not tied to a specific course, including:

    • A default landing view for cross scope review and management.

    • A way to navigate into course scoped and library scoped management views from that entry point.

  • R6.4 Support cross scope review and user audit in the Administrative Console, including:

    • A user centered view that shows a user’s roles across courses and libraries.

    • Clear indication of whether access is local to a resource or inherited from higher level scopes.

  • R6.5 Provide filters for cross scope views to help admins narrow what they are reviewing, including:

    • Resource type filtering (courses, libraries, all).

    • Scope level filtering (organization, global).

    • Basic search (user, course, library).

6. Known issues and technical debt

The Libraries AuthZ MVP shipped with some planned behaviors and flows cut for time, and we knowingly introduced a bit of technical debt in the new AuthZ stack. We want to reduce both before leaning on this foundation for Studio.

Most of the relevant issues for the next release are tracked with the verawood label in the openedx-authz repository:

This list is not exhaustive, but it covers the most critical items we know about today.

  • Course files and uploads are not versioned today, changes can become learner visible immediately, there is no publish step for files like there is in Libraries.

  • Course import is a superset capability, it can modify most course settings and content, including draft and published content.

  • Some settings pages are served by single endpoints (for example Schedule and Details, Advanced Settings), so splitting permissions below the page level increases implementation effort.

7. Open questions

These topics need alignment before we lock the scope for authoring:

7.1 Technical discovery

  • Legacy course roles and LMS behavior
    How do we keep Admin, Staff, Limited Staff, Data Researcher consistent across legacy LMS checks and the new AuthZ service when granting or revoking those roles?

  • Enforcement outside Studio
    Several course capabilities that are typically associated with authoring may be intertwined with, or enforced in, surfaces outside Studio, and therefore require careful review. We also need to account for capabilities that can be changed in both Studio and the LMS, such as role assignment, to ensure consistent enforcement and avoid conflicting sources of truth. Which of these can we realistically cover in this iteration, and how do we enforce validations when actions happen outside Studio?

  • Learning Core and publish permission
    Learning Core won’t be a viable backend for serving courses in the Verawood timeline. It should have minimal impact on RBAC, but it might be a bit tricky because there are certain actions that auto-publish, so the line between editing and publishing gets blurry. The main examples I can think of are course level settings, grading policy, and static assets. Learning Core offers the ability to stage these in draft mode, but you can’t do that in ModuleStore/ContentStore today.

  • Legacy Studio frontend
    Is the deprecated legacy Studio UI fully removed by Verawood? If not, how do we keep it working with the new AuthZ system, or do we remove it altogether?

  • Extensibility of openedx-authz
    How can other modules define permissions without having to add them into the core openedx-authz repo?

7.2 Product discovery

  • Coverage of functional areas
    Can we cover all of the following with the new roles and permissions, or do we need to phase them? Course team management, content editing, course settings, grading, schedule and details, certificates, advanced settings, course updates, groups, page and resource management, tool access.

  • Taxonomies and remaining course features
    If we have capacity, do we extend this iteration to taxonomy management, or leave it for a later phase?

  • Custom roles
    Do we aim for a constrained “custom role” mechanism in this iteration, or defer a general-purpose role builder to a later release?