Conversation
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @rodmgwgu! 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. |
71278c7 to
e3d19f1
Compare
ba61be7 to
a7ba6ac
Compare
mphilbrick211
added
the
mao-onboarding
a7ba6ac to
16e9cc8
Compare
mariajgrimaldi
left a comment
mariajgrimaldi
left a comment
There was a problem hiding this comment.
A few comments for you to review! This will probably will need to be updated according the changes down the stack, mainly the model fields.
| __all__ = [ | ||
| "OriginKind", | ||
| "AuthzSchemaSource", | ||
| "AuthzPermissionCategory", | ||
| "AuthzPermissionDefinition", | ||
| "AuthzRoleDefinition", | ||
| "AuthzRolePermission", | ||
| "AuthzCategorySource", | ||
| "AuthzPermissionSource", | ||
| "AuthzRoleSource", | ||
| "AuthzRolePermissionSource", | ||
| "origins_for_role", | ||
| "origins_for_permission", | ||
| "origins_for_category", | ||
| "origin_for_role_permission", | ||
| ] |
There was a problem hiding this comment.
nit: I think it's nice we document we try to prefix all models with authz for easier identification?
| content_digest = models.CharField(max_length=64, blank=True, default="") | ||
| schema_version = models.CharField(max_length=16, blank=True, default="") |
There was a problem hiding this comment.
Is it okay to allow this to be empty? Just making sure.
| created_at = models.DateTimeField(auto_now_add=True) | ||
| updated_at = models.DateTimeField(auto_now=True) |
There was a problem hiding this comment.
Maybe we can create an abstract model for managing these timestamps
| # --------------------------------------------------------------------------- | ||
|
|
||
|
|
||
| def origins_for_role(role_id: str) -> list[str]: |
There was a problem hiding this comment.
Would this (and below) be better implemented as managers?
|
|
||
|
|
||
| class AuthzRolePermission(models.Model): | ||
| """A single role-permission-scope grant (one per rendered Casbin ``p`` row). |
There was a problem hiding this comment.
nit: I wouldn't call this a grant, since technically it doesn't grant any permission. This adds semantic meaning to each Casbin row, but the actual permission attribution is still managed by Casbin. It might be a bit misleading as is.
3edee8d to
6b463f9
Compare
6b463f9 to
6a26f70
Compare
5 participants
Problem
Compiled definitions and their provenance need first-class tables. Casbin
prows alone cannot answer which distribution contributed a role, whether a contribution was a base definition or an extension, or which rows the schema loader owns — and ownership is what makes later pruning safe instead of guesswork (ADR 0025).Approach
openedx_authz/models/schema.py— definition tables (permission categories, permission definitions, role definitions, role-permission grants) and provenance tables (schema sources plus one source-link table per definition kind)openedx_authz/migrations/0011_authz_schema_definitions.py— additive migrationopenedx_authz/models/__init__.py— export the new moduleSource attribution is recorded at the role-permission grain, so contributions from different applications to the same role stay distinguishable. The query helpers (
origins_for_role,origins_for_permission,origins_for_category,origin_for_role_permission) land with the models.Nothing writes to these tables in this PR — the applier does, in 7/8.
Manual testing instructions
Confirm the migration is complete and applies cleanly:
./manage.py makemigrations --check --dry-run openedx_authz # No changes detected tutor dev run cms ./manage.py cms migrate openedx_authzRollback plan
Revert this PR and run the reverse migration if it was applied. The migration is purely additive — it creates new tables and alters none — so a revert cannot affect existing data.
Retro compatibility
No authorization behavior changes. The tables are created empty and nothing reads or writes them until the applier lands.
AI Usage
Kiro was used to assist on feature planning and implementation. Implementation was done step by step with human guidance and validation, based on the ADRs.
Stack (5/8) — #446 split into reviewable pieces. Bases chain bottom-up; merge in order.
rod/authz-schema-validator)rod/authz-schema-renderer— policy rendererrod/authz-schema-applier— schema applierload_authz_schemacommand, version bump and changelogMerge checklist:
0011, additive). If another0011lands on main first this needs renumbering