docs: define the authorization schema lifecycle - #422
Conversation
openedx-webhooks
added
open-source-contribution
|
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. |
rodmgwgu
left a comment
rodmgwgu
left a comment
There was a problem hiding this comment.
I'm aligned with most of what's defined in this ADR, just added some comments for discussion. Thanks!
| Decision | ||
| ******** | ||
|
|
||
| #. Lifecycle vocabulary |
There was a problem hiding this comment.
I see this is not rendering as a number in the readthedocs preview.
|
|
||
| Static and dynamic roles share the same set of names, so neither kind can reuse a name that already exists. The dynamic role API rejects a name used by a static role, and deployment stops when a new static role conflicts with an existing dynamic role. | ||
|
|
||
| For example, an administrator cannot create a dynamic ``course_observer`` role when an application already defines a static role with that name. If the dynamic role existed first, a deployment that introduces the static role stops and reports both the contributing package and the conflicting database record, leaving both definitions unchanged. |
There was a problem hiding this comment.
Should we define a naming convention for dynamic roles? like custom_<user defined name>, to avoid name clashes? (although this convention wouldn't go in this specific ADR).
|
|
||
| Before writing to the database, the compiler reports the categories, permissions, roles, and role-permission relationships that will change, including changes caused by a higher-priority contribution. Validation errors and failed tests stop deployment before the database changes. | ||
|
|
||
| Removing a static role also removes its role-permission relationships. If users still have that role, deployment stops and reports the assignments that must be removed or moved to another role. For example, ``course_observer`` cannot be removed while Alice still has that role. |
There was a problem hiding this comment.
How will the system detect a removed role or role-permission relationship? will it do a diff between the newly rendered schema vs the one existing in the DB? should we specify this here?
|
|
||
| Before writing to the database, the compiler reports the categories, permissions, roles, and role-permission relationships that will change, including changes caused by a higher-priority contribution. Validation errors and failed tests stop deployment before the database changes. | ||
|
|
||
| Removing a static role also removes its role-permission relationships. If users still have that role, deployment stops and reports the assignments that must be removed or moved to another role. For example, ``course_observer`` cannot be removed while Alice still has that role. |
There was a problem hiding this comment.
Has a flag or something similar been considered to force the deletion, so we don't have to manually delete the assignments?
5 participants
Description
The authz schema needs a predictable path from files contributed by applications to the policy stored in the Casbin adapter. That process must preserve dynamic roles and user assignments already in the database, avoid duplicate rows when deployment runs again, and stop safely when definitions conflict or a removed role still has assignments.
This ADR defines the schema lifecycle from discovery through consumption and places compilation during deployment. It also defines storage ownership, idempotent updates, role identifier conflicts, change reporting, removed-role handling, and the administrative fallback for generated rows.
Merge checklist:
Check off if complete or not applicable: