feat: split read vs write authz checks for group configurations - #39010
feat: split read vs write authz checks for group configurations#39010wgu-taylor-payne wants to merge 1 commit into
Conversation
|
Thanks for the pull request, @wgu-taylor-payne! 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. |
9f0f375 to
425bfa2
Compare
425bfa2 to
3f057ca
Compare
| if request.method == 'GET': | ||
| course = get_course_and_check_view_group_configurations_access(course_key, request.user) | ||
| else: | ||
| course = get_course_and_check_manage_group_configurations_access(course_key, request.user) |
There was a problem hiding this comment.
Not to block this PR but I'm a bit concerned about adding more and more code branches when checking for permissions. I understand it's best to be surgical about the changes to not break other unrelated code sections but I'm not sure about the maintainability long-term. At least we should ensure that all the branches are thoroughly tested. Can we review testing and make sure we are?
There was a problem hiding this comment.
We might be missing L200 but that might be related to when this was introduced?
There was a problem hiding this comment.
This endpoint has a GET/POST split, which I have refactored in my most recent changes. I think the GET is legacy and may no longer be actively used, but in any case, I have moved from the manage check to a view check for a GET request.
| assert resp.status_code == status.HTTP_200_OK | ||
| assert resp.data["can_manage"] is True | ||
|
|
||
| def test_editor_can_view_group_configurations(self): |
There was a problem hiding this comment.
Is the edit (POST) in group_configurations_list_handler ever tested?
There was a problem hiding this comment.
I added tests for editor and auditor to test POSTing to group_configurations_list_handler.
rodmgwgu
left a comment
There was a problem hiding this comment.
Tested in my local for the following roles:
course_auditor
course_editor
course_staff
no role
All passed as described √.
rodmgwgu
left a comment
There was a problem hiding this comment.
Code looks good and works as described. Thanks!
BryanttV
left a comment
There was a problem hiding this comment.
Thanks @wgu-taylor-payne! The changes work as expected on my local.
Use COURSES_VIEW_GROUP_CONFIGURATIONS for read access and COURSES_MANAGE_GROUP_CONFIGURATIONS for write access when authz is enabled. Course Auditors can now view group configurations in read-only mode while keeping write access restricted. Updates both the REST API v1 view and the legacy view handler. Add a can_manage flag to the v1 response so the frontend can decide whether to render edit controls. In group_configurations_list_handler, handle GET (which only redirects to the MFE or returns 406) up front with just the view-permission check, avoiding the previously wasted modulestore course-block load; the block is now loaded only for the POST (create) path. Tests cover the write split on the legacy list handler (PostGroupConfigurationsListHandlerAuthzTest): staff and editor (which hold manage_group_configurations) can POST; the auditor and users without the permission are denied.
f909598 to
265394a
Compare
Description
Updates group configuration endpoints to use
courses.view_group_configurationsfor GET access andcourses.manage_group_configurationsfor write access. Adds acan_manageflag to the REST API v1 response so the frontend can conditionally render edit controls.Previously, both the REST API v1 view and the legacy handler used
COURSES_MANAGE_GROUP_CONFIGURATIONSfor all access including reads. This blocked Course Auditors from viewing group configurations entirely. Per the design in openedx/openedx-authz#283, auditors should see the page in read-only mode.User roles impacted: Course Auditor — can now view (but not edit) group configurations. Course Editor retains full access (has both view and manage permissions).
Changes:
cms/djangoapps/contentstore/rest_api/v1/views/group_configurations.py: UseVIEW_GROUP_CONFIGURATIONSin decorator, addcan_managecheckcms/djangoapps/contentstore/rest_api/v1/serializers/group_configurations.py: Addcan_managefieldcms/djangoapps/contentstore/views/course.py: Check view permission on a GET requestRollback: Gated behind
AUTHZ_COURSE_AUTHORING_FLAG— disabling the flag reverts to legacy behavior.Supporting information
courses.view_group_configurationsenforcement in openedx-platform openedx-authz#401Testing instructions
AUTHZ_COURSE_AUTHORING_FLAGfor a coursecourse_auditorroleGET /api/contentstore/v1/group_configurations/{course_id}→ 200 withcan_manage: falsecourse_editor→ 200 withcan_manage: truecourse_staff→ 200 withcan_manage: trueGET /group_configurations/{course_key}with auditor → should succeedDeadline
None
AI Usage
Kiro was used as a development partner throughout this PR. I directed the implementation approach, defined scope, reviewed generated code, and made design decisions — Kiro researched the codebase, wrote the implementation and tests, ran lint/type checks, and iterated on fixes. I verified the changes manually against a local Tutor dev environment and reviewed the final diffs before submitting.