docs: separate static and dynamic roles - #420
Conversation
|
Thanks for the pull request, @mariajgrimaldi! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
openedx-webhooks
added
open-source-contribution
rodmgwgu
left a comment
rodmgwgu
left a comment
There was a problem hiding this comment.
Looks good, just a couple of things that came to mind while reading this (though I don't think these concerns should be solved here, just to keep in mind for future ADRs):
- What happens if an administration want's to remove or 'hide' static roles? will we allow this in the future?
- Will we allow an administrator to modify one of the static roles dynamically?
BryanttV
left a comment
BryanttV
left a comment
There was a problem hiding this comment.
Thanks @mariajgrimaldi, I just have a minor comments.
|
|
||
| Applications, such as Django apps or IDAs, define static roles in the Open edX Authorization schema (authz schema). Because the application owns these roles, changes to them are made in the schema and released with the application. | ||
|
|
||
| Administrators create dynamic roles through the application, and the authz model stores both their definitions and their user assignments. This keeps administrator-managed data separate from the static definitions in the authz schema. |
There was a problem hiding this comment.
Would operators and administrators be the same actor?
There was a problem hiding this comment.
Not necessarily. An administrator has Django admin/staff access, while an operator would be a site operator as in https://docs.openedx.org/en/latest/site_ops/index.html. An admin doesn't necessarily operate a site but a site operator could be an administrator (could have django admin access for site operator tasks). We haven't specified which kind of user would be able to create roles (dynamic or static) yet but we could start with those kind of users.
As I see it, static roles that need a deployment to work would need site operator access while dynamic roles might need django admin or similar access.
what do you think, @rodmgwgu @gviedma-aulasneo?
There was a problem hiding this comment.
Yes, I agree with what you described @mariajgrimaldi, the idea for having dynamic roles is for non-programmers or non-technical people to be able to define these roles as configuration without needing a redeploy.
| Static and dynamic definitions | ||
| ============================== | ||
|
|
||
| Applications, such as Django apps or IDAs, define static roles in the Open edX Authorization schema (authz schema). Because the application owns these roles, changes to them are made in the schema and released with the application. |
There was a problem hiding this comment.
Should we reference the authz schema (ADR-17) here for more context?
There was a problem hiding this comment.
Just to be clear, defining how these "dynamic roles" are created would be out of scope for this effort, correct?
There was a problem hiding this comment.
Yes! We're only trying to draw a line between the kind of roles that exist.
I think we should allow this kind of operation. What we'd need to figure out is whether we'd need a configuration file (which will require a deployment) or we'd allow to do this in runtime. Maybe we can include some of this rationale in a new ADR where we define what kind of operations we'd support in role extensions. Here's the ADR: #430 I think we can take the conversation there!
I wouldn't be opposed to this but we'd need to be careful about how we handle change traceability so we ensure site operators have a way to audit an out-of-the-box was changed at runtime and doesn't match static definitions anymore. We might need to discuss auditability for this specifically. Maybe this convo fits here: #425 |
5 participants
Description
Open edX needs to support roles defined by applications as well as roles created by administrators. These roles have different owners and lifecycles, but users should be able to work with both through the same authorization APIs.
This ADR separates static and dynamic roles. Applications define static roles in the authz schema, while administrators create dynamic roles through the authz model and APIs. This boundary gives the following ADRs a clear basis for defining the schema, deployment lifecycle, discovery, translations, and API behavior.
Merge checklist:
Check off if complete or not applicable: