Open edX role-based access for course authoring

The practical difference between role-based authorization and a per-course staff list is where the grant is made and where it is kept. In a per-course model, a person with course staff rights adds a named user to each course that user should author in, so the grant lives beside that course. With openedx-authz, access is expressed as a role assigned at a scope such as a course, an organization or a site, so one grant can cover many courses. Before you enable it, decide which team owns those grants, because that team controls who can widen access across the platform.

Three questions shape the rollout: who grants access, where the grant is recorded, and how it is checked when a user opens Studio. Confirm each answer for your release in the official documentation and on a test instance before you plan the migration. Ask your operations team to show you where the grants are stored, whether they can be exported for review, and how a lookup for one account is resolved. An auditor will ask the same questions, so the answers should be written down before the first batch of users moves.

Inheritance is where access mistakes usually hide. A role assigned at an organization or site scope may apply to the courses beneath it, but the reader should not assume this until it is verified in their own environment. Create a test user, assign a role at one scope, open courses at each level in Studio, and record what the user can and cannot edit. Then remove the role and repeat the check, because revocation matters as much as the grant. Do not rely on inherited access for any migrated batch until both tests pass.

Verawood changes the authoring surface these permissions govern. It added a new Studio sidebar, an AI Extensions Framework, and tagging and taxonomy management. Each is a place where an author takes action, so each needs a test account with a deliberately limited role. Check which sidebar entries, taxonomy actions and AI features appear for that account, and whether authors who should not use AI features can still see them. If a role does not hide a feature, plan a separate control for it and record that control as an open item before go-live.

Move existing course roles to the new scopes in small groups so that each group can be checked, and reversed if needed, before the next one starts. Group courses by the organization or owning team that manages them, because that is how the scopes for Studio will be drawn. Begin with a group that has a clear owner and few instructors who also work on other teams' courses. Verawood is the current named release, published on 30 July 2026, and Willow is listed for December 2026 as the release where this authorization model is planned to become the default. Confirm the exact behavior of the target release in its release notes before you plan the first batch.

Before any change to a batch, create a rollback point. In practice this means a backup of the MySQL data that holds role assignments, a copy of the site and course configuration in your deployment repository, and an export of every role assignment for the courses in the batch. Keep the audit list in a versioned file with one row per course and user. Record the role before the change, the scope after the change, the batch identifier and the approver. Rehearse the rollback in staging on the same batch. Ask your vendor or the release notes which tables and services store role data, so you know that a restore returns every assignment, not only the course-level ones.

Some assignments will not map cleanly to the new scopes. Illustrative examples include a contractor with instructor rights on courses owned by two organizations, a former staff member whose account still holds course staff rights, or a team lead who needs access to one course while the team's new scope is wider. Reconcile each case into one of three outcomes: assign the narrower scope, keep the assignment as a named exception with an owner and a review date, or remove it. Write every exception into the audit list. Do not let the automated mapping resolve these cases silently, because the audit list is the only record of why a user kept or lost access.

Each batch needs approval from three roles before it runs: the lead of the owning team for the courses in the batch, the platform operator who executes the change, and a security or compliance approver who reviews the exceptions. No batch proceeds until all three have signed the audit list for that batch. Keep the sign-off record with the rollback point so that an auditor or internal reviewer can trace each change from request to completion. Agree in writing who may approve exceptions and how long they may stay open.

The number of courses and users is the main driver of effort. More courses mean more batches, more owners to coordinate and more rehearsals, and more users mean more exceptions to reconcile. Test batch size in staging with a copy of production role data. Measure how long a batch takes to apply, verify and roll back, and count the exceptions it produces. Use those results to choose a batch size for production. When you ask a partner or internal team for a quote, ask for the batch count and size assumed, the number of staging rehearsals included, who performs the sign-off reviews, and what recurs after the migration, such as exception reviews.

Verawood is the current named Open edX release, published on 30 July 2026. Willow is listed for December 2026 and Xylon for June 2027. Willow is the release where role-based authorization becomes the default for Studio, so a platform that enables it on Verawood is preparing for a change that arrives whether or not the course migration is finished. Open edX states that the latest named release is the only supported release and that it cannot support more than one at a time. Once Willow is out, an installation still running Verawood will need an upgrade path to follow the default change, and that path will not wait for your role migration to finish.

Treat the Verawood work and the Willow upgrade as two projects with separate scope, owners and acceptance tests. The Verawood project enables the authorization layer for Studio, sets the scope at course, organization or site level, and migrates existing course roles in controlled batches. The Willow project moves the platform to a supported release and confirms that the authorization behavior your teams rely on still holds once the default changes. Keeping them apart lets you roll back a batch of role changes without also reversing a platform upgrade, and it stops the Willow date from being used as a deadline to finish a migration that was never tested.

Run the migration on Verawood first, in batches small enough that each course team can check its own courses. After each batch, confirm that instructors, course team members and staff can still open Studio, edit content, publish and manage course access, and that no user has lost a permission they need. Record the role mapping as a versioned document: each legacy course role, the authorization role it maps to, the scope it applies at (course, organization or site), any exceptions, and who approved them. This record is the main input to the Willow project, and it is the evidence an internal reviewer or external auditor will ask for.

When the Willow release notes are published, read them against your mapping before you set an upgrade window. Confirm the Willow change list yourself: which authorization behaviors change, which settings or defaults move, and whether any role your mapping depends on is renamed, removed or narrowed. Do not assume that Verawood test results carry over unchanged. If you ask a partner to quote the Willow upgrade, base the request on that change list, your current Tutor version, your custom plugins and the number of sites, so the quote reflects what your installation actually needs to change.