After stabilizing Authoring and completing the new roles, the next step should be to define how the AuthZ model expands into the next platform surface.
Instructor Dashboard is the best first target for this definition work because it is directly connected to course roles, but it also exposes the limits of the current model: LMS-based course administration, learner data, grading, membership, and legacy role behavior.
This initiative should not be treated as a full Instructor Dashboard implementation. It should define the reusable expansion pattern that future AuthZ areas will follow.
Expected outcomes
- A clear list of Instructor Dashboard sections affected by the new Authoring roles.
- A permission map for those sections.
- A role behavior matrix for Course Admin, Staff, Course Editor, and Course Auditor.
- Compatibility notes for Limited Staff, Beta Tester, and Data Researcher.
- UX/UI designs for the affected areas.
- A recommended implementation slice for the first Instructor Dashboard changes.
- A reusable pattern for how the AuthZ and Console foundations should expand into new permission areas.
Key questions to answer
- What does Instructor Dashboard need from the new course role model?
- What does the AuthZ model need in order to support future expansion without bespoke implementations?
- Which Instructor Dashboard areas should Course Editor access?
- Which Instructor Dashboard areas should Course Auditor access?
- Which areas should remain limited to Course Admin or Staff?
- Which actions should move to the Administrative Console instead of staying in Instructor Dashboard?
Description
Allow an installed module to contribute new roles and permissions (including the metadata needed by the Administrative Console) without changing openedx-authz critical code paths or adding role-specific frontend code.
-
Spike: Extensibility Proposal for Willow Instructor Dashboard Use Case
-
Guiding use case: Instructor Dashboard.
-
Context: The PoC already showed that Casbin can load, assign, and enforce new role and permission strings. This epic covers the missing definition layer around that behavior: contribution/discovery, metadata, validation, and role-agnostic APIs.
-
Scope covered: Use cases A1, A2, A5, and A6 (add a role with existing permissions; add a role with new permissions; add new/existing permissions to a built-in role). Uses the current scope and subject.
-
Out of scope: new scope types, new subject types, scope REST discovery, and plugin removal.
After stabilizing Authoring and completing the new roles, the next step should be to define how the AuthZ model expands into the next platform surface.
Instructor Dashboard is the best first target for this definition work because it is directly connected to course roles, but it also exposes the limits of the current model: LMS-based course administration, learner data, grading, membership, and legacy role behavior.
This initiative should not be treated as a full Instructor Dashboard implementation. It should define the reusable expansion pattern that future AuthZ areas will follow.
Expected outcomes
Key questions to answer
Description
Allow an installed module to contribute new roles and permissions (including the metadata needed by the Administrative Console) without changing openedx-authz critical code paths or adding role-specific frontend code.
Spike: Extensibility Proposal for Willow Instructor Dashboard Use Case
Guiding use case: Instructor Dashboard.
Context: The PoC already showed that Casbin can load, assign, and enforce new role and permission strings. This epic covers the missing definition layer around that behavior: contribution/discovery, metadata, validation, and role-agnostic APIs.
Scope covered: Use cases A1, A2, A5, and A6 (add a role with existing permissions; add a role with new permissions; add new/existing permissions to a built-in role). Uses the current scope and subject.
Out of scope: new scope types, new subject types, scope REST discovery, and plugin removal.