AuthZ Authoring: Milestones

M0 - Coexistence model for legacy role assignment

Purpose

Enable safe development where Studio can start enforcing authorization via the new AuthZ path, while legacy roles (Staff, Admin, etc.) must keep working across the rest of the platform.

Outcome

A documented and working coexistence model for assigning and revoking legacy roles across both systems, plus the minimum tooling to migrate, validate, and safely iterate on the main branch.

Definition of Done

• Source of truth for this phase is defined and documented, including how assign and revoke behave when two systems are in play, and what guarantees we provide.

• Minimal roles for technical validation exist, including at least one role that grants a single permission, to validate enforcement and debug authorization behavior in isolation.

• Migration tooling exists, enough to keep assignments consistent across systems during development, and to recover from drift when it happens.

• First Studio surface is selected, and the cut is explicit, this surface can use the new AuthZ enforcement path when enabled, everything else stays on legacy.

• Safe gating for main branch iteration is implemented, new enforcement is OFF by default in production like environments, enabled only via feature flags.

• Rollback strategy is agreed, plus a documented revert plan if needed.

• Staging environment exists and is usable for validating the coexistence model end to end, if it does not exist today, creating it is part of M0.

• Known limitations are documented, and we have a short operational playbook for debugging and recovery during the transition.

Dependencies

Engineering decision on coexistence strategy, availability or creation of a staging environment, and agreement on the single role management entry point supported during the transition.

Alignment items M0 must close

• First Studio cut, proposal: Group Settings is the proposed initial surface for the first AuthZ enforcement cut.

• Role assignment entry points: during the transition, we will support Instructor Dashboard only for assignment and revocation, we will not build additional role management interfaces in Studio, Django admin, or the Admin Console for this phase.

• Migration approach: what “migration tooling” covers in this phase, and what guarantees we can realistically provide.

• What “consistent enough” means in this phase, especially for revoke edge cases and cross tool behavior for Staff and Admin. (logs, refresh, etc)

M1 - Parity for legacy Staff and Admin, plus first AuthZ cut running in Studio

Purpose

Confirm we can run the coexistence model without breaking legacy roles, and start exercising the first Studio enforcement cut in a controlled way.

Outcome

Staff and Admin behaviors are validated as unchanged across the critical workflows for this phase, and the first Studio surface can be enforced via new AuthZ behind flags.

Definition of Done

• Parity baseline is documented for Staff and Admin, covering the critical workflows and surfaces that must remain unchanged in this phase.

• Parity is validated end to end in staging, using the coexistence model from M0, no unexpected access loss for Staff or Admin.

• First Studio cut is live behind flags, proposal surface is Group Settings, flag OFF equals current behavior, flag ON enforces via new AuthZ for that surface only.

• Permission mapping for the cut is complete, all actions inside the surface are mapped and enforced consistently.

• Known limitations are explicitly listed, with mitigation or follow up plan, no silent regressions.

• Operational readiness exists, short troubleshooting guide for access issues and clear escalation path.

Dependencies

M0 completed, staging available, agreement on the list of critical workflows and surfaces that define Staff and Admin parity for this phase.

M2 - Admin Console UI for Courses, plus higher level scopes

Purpose

Ship the Administrative Console surfaces to manage course roles using the AuthZ service, and unlock bulk and cross scope operations so admins stop repeating the same assignment dozens of times.

Definition of Done

• Courses are a first class resource in the Console.

  • Console supports a course scoped team view that lists local members and their roles.

  • Console also shows other users with access via higher scopes in a separate section.

• Cross scope assignment and revocation is live for the agreed scopes.

  • Admin can assign and revoke roles on: All courses, All courses in Org X, All libraries, All libraries in Org X.

  • Bulk operations exist for many users on one scope and one user across related scopes, aligned with the scopes above.

• Auditability is included.

  • Every assignment and revocation is auditable, who did it, when, and on which scope.

• Entry points exist from Studio to the Console.

  • A deep link from Studio opens the Console in the correct course context, with a clear back path.

  • A general entry point from Studio also exists for cross scope navigation and review.

• Baseline UX filters for cross scope review.

  • Filters exist for resource type, scope level, and basic search (user, course, library).

Dependencies

• A working staging environment exists for this work, otherwise it is created as part of the milestone.

• M0 and M1 foundations exist, meaning the AuthZ service models the legacy roles and the transition story is stable.

M3 - New authoring roles, taxonomy permissions, publishing isolated

Purpose

Introduce the new authoring roles you already defined, include taxonomy permissions in the model, and isolate publishing as an explicit permission boundary.

Definition of Done

• New authoring roles exist and are assignable.

  • Roles are created in AuthZ, show up in the Admin Console, and can be assigned and revoked using the M2 scopes.

  • Role descriptions and boundaries are documented, so admins understand what each role can and cannot do.

• Permissions are mapped and enforced for in scope Studio surfaces.

  • All actions in the in scope surfaces are mapped to permissions.

  • Enforcement in Studio respects those permissions when the flag is enabled, and remains safe to iterate on main.

• Taxonomy permissions are included.

  • Taxonomy related actions are mapped to permissions and enforced consistently with the new roles.

  • Any taxonomy actions that remain legacy only are explicitly listed as limitations.

• Publishing is isolated as a permission boundary.

  • Publishing is not included in any new role in this phase.

  • Legacy Staff and Admin retain existing publishing behavior.

  • The separation is explicit in the permission mapping and enforcement logic, so publishing does not leak through other capabilities.

• Known limitations and operational notes are documented.

  • Clear list of what is still legacy only, and how admins should reason about access during the transition.

  • Troubleshooting and escalation path for access issues.

Dependencies

• M2 Admin Console flows and scopes are live.

• Staging is available for validation.

• Tech confirms publishing isolation approach.