refactor: split REST API views by domain ownership and package layout - #378
refactor: split REST API views by domain ownership and package layout#378mariajgrimaldi wants to merge 6 commits into
Conversation
Moves the five Admin-Console-shaped endpoints (AdminConsoleOrgsAPIView, ScopesAPIView, TeamMembersAPIView, TeamMemberAssignmentsAPIView, AssignmentsAPIView) into a new admin_console/ subpackage, and WaffleFlagStatesAPIView into a new course_authoring/ subpackage, per the ownership and layout rules being recorded in ADR 0016 and ADR 0017. PermissionValidationMeView, RoleUserAPIView, RoleListView, and UserValidationAPIView remain in views.py as generic Authorization endpoints, with no reference to any specific consumer's packaging; that reasoning lives in admin_console/course_authoring's own docstrings and in ADR 0017. No URLs change; tests move alongside their views. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…line ADR 0016 records the domain-ownership audit of openedx_authz.rest_api: which endpoints are Authorization's own data, which is the one exception (WaffleFlagStatesAPIView), and why generic endpoints must not depend on another domain's concepts (the rationale PR #361 ran into). ADR 0017 names the package-layout convention the admin_console/ and course_authoring/ subpackages apply, so a future endpoint has a placement rule instead of a fresh discussion. ADR 0015 gains an addendum reflecting ADR 0016's conclusion, the actual toggle_target_removal_date (2027-06-09) and upstream tracking issue for the flag, and the confirmed details of openedx-platform's own ToggleStateView as prior art for the rejected /api/toggles/v0/state/ alternative. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
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. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. Where 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. |
pylint 4.0.4/astroid 4.0.4 no longer needs the too-many-positional-arguments suppression on these test/model signatures, flagging the old comments as useless-suppression. Also trims trailing blank lines flagged by trailing-newlines, fixes a line-too-long, and drops an unused import in the new admin_console test module. openedx_authz/rest_api/v1/filters.py was left behind, byte-identical and unreferenced, after admin_console/filters.py replaced it in the package layout split (ADR 0017).
9d909b3 to
fdde385
Compare
Adds two consequences: callers must resolve their own scope against the raw override lists (course -> org -> global precedence), with frontend-app-admin-console's useCourseAuthoringFlag hook (PR #176) as the reference implementation, and the endpoint takes no client-supplied parameters, so CSRF doesn't apply since it's GET-only and IsAuthenticated is what actually gates access.
The concern isn't request forgery, this is a GET endpoint with no client-supplied parameters to forge. It's that the response isn't scoped per caller: any authenticated user gets every org/course override on the instance, with no additional permission check beyond IsAuthenticated. Also trims the Consequences and Addendum prose, which had grown longer than this repo's established ADR style (see docs/decisions/0012 and 0014 for reference).
Drop the "Decision item 4 said/left" framing: an ADR should state its current position directly, not cite an earlier numbered item by name as if quoting it. Also fixes a comma splice and cuts an unnecessary "not by caller" contrastive clause.
6762621 to
a2138eb
Compare
Description
This PR covers our strategy to solve issue #372 across three parts:
PermissionValidationMeView,RoleUserAPIView, andRoleListViewwon't become flag-aware, since Authorization endpoints can't compute or expose another domain's data.WaffleFlagStatesAPIViewexposes the flag's raw state instead, andfrontend-app-admin-console'suseCourseAuthoringFlaghook (#176) resolves it client-side.openedx_authz.rest_apiby domain ownership, and ADR 0017 turns that audit into a package-layout convention so a future endpoint has a placement rule.rest_api/v1/admin_console/, andWaffleFlagStatesAPIViewmoves intorest_api/v1/course_authoring/, so the package boundary matches the domain boundary ADR 0016 draws. No URLs change, and no endpoint behavior changes; this makes Authorization's boundaries visible in the code, alongside the documentation.Fixes #372
Testing instructions
CI tests pass, no change in behavior.
Merge checklist:
Check off if complete or not applicable: