You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to start the unfinished followup from OEP-9 of starting to switch over existing authorization checks in the Open edX code to follow the recommended pattern (basically "Django authorization API using bridgekeeper as the backend)."
A/C:
Write up an execution plan in the Open edX Confluence for switching over the code identified in the discovery doc to switch over to the recommended API from OEP-66. No business logic should be changed at this point, just separation of authorization check implementations from usage (and de-duplication of essentially identical helper functions).
Communicate the plan and timeline to stakeholders (owning teams, SRE, etc.) and adjust as needed based on feedback
Chunk the work from the discovery doc into separate issues that can be worked on in parallel, and add them to a tasklist in this issue
Merge and deploy at least 1-2 PRs to shake out any bugs in the process before starting work on the remaining issues
Complete the remaining issues generated above
Do another round of discovery for any similar refactoring that still needs to be done, and create a new issue for it
Perform a retrospective on the process and schedule or shelve the next round of refactoring as appropriate
The text was updated successfully, but these errors were encountered:
The topic of bridgekeeper maintenance status came up in https://twou.slack.com/archives/C04B987KHK5/p1694531725289039 . rules is more actively maintained, but isn't really getting any new features; bridgekeeper is ahead in terms of useful features, but behind on routine maintenance. I think our first preference right now is help the bridgekeeper maintainer catch up on Python & Django version testing, with forking as a fallback if that doesn't work out. Sticking with rules would leave us with less maintenance overhead but a feature gap that we'd have to figure out how to plug (and the rules maintainer has been opposed to adding those features; see dfunckt/django-rules#40 for context).
The Roles and Permissions squad has been doing some work to clean up and enhance the use of authorization in Open edX, resulting in:
We would like to start the unfinished followup from OEP-9 of starting to switch over existing authorization checks in the Open edX code to follow the recommended pattern (basically "Django authorization API using bridgekeeper as the backend)."
A/C:
The text was updated successfully, but these errors were encountered: