feat: authorize advanced settings endpoints via openedx-authz when fl… by wgu-taylor-payne · Pull Request #38009 · openedx/openedx-platform

wgu-taylor-payne · 2026-02-13T22:26:14Z

Description

Add the option to authorize with openedx-authz for the advanced settings related endpoints. If the AUTHZ_COURSE_AUTHORING_FLAG is enabled for the course, then the system will do the permission check against openedx-authz.

This functionality depends on features introduced to openedx-authz in version 0.21.0.

Supporting information

Resolves #37926.

Testing instructions

To run the relevant automated tests:

pytest --ds=cms.envs.tutor.test \
"cms/djangoapps/contentstore/rest_api/v0/tests/test_advanced_settings.py::AdvancedSettingsAuthzTest" \
"cms/djangoapps/contentstore/rest_api/v1/views/tests/test_proctoring.py::CourseProctoringErrorsViewTest"

To manually test:

Ensure that the new policy is loaded by running ./manage.py cms load_policies
Ensure that the AUTHZ_COURSE_AUTHORING_FLAG flag is enabled for the given course (see feat: Add Waffle flag for AuthZ for Course Authoring #37985).
If staff or admin, you should be able to access the advanced settings page for any course (e.g. http://apps.local.openedx.io:2001/authoring/course/course-v1:OpenedX+DemoX+DemoCourse/settings/advanced)
If not staff or admin, then you will have to assign the COURSE_STAFF role to the user with the scope being the course you are testing access for. Afterwards the user should have access to the advanced settings page.

Deadline

Verawood release

openedx-webhooks · 2026-02-13T22:26:20Z

Thanks for the pull request, @wgu-taylor-payne!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To 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:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

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:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

…ag enabled

…when flag enabled

bmtcril · 2026-02-17T13:51:08Z

common/djangoapps/student/auth.py

+        bool: True if user has permission, False otherwise
+    """
+    if core_toggles.AUTHZ_COURSE_AUTHORING_FLAG.is_enabled(course_key):
+        return authz_api.is_user_allowed(user.username, MANAGE_ADVANCED_SETTINGS.identifier, str(course_key))


The previous version of this check also checked whether the DISABLE_ADVANCED_SETTINGS feature flag was set. Is that no longer necessary?

The only path that checks this feature flag is when the proctoring errors view calls has_studio_advanced_settings_access. This path still executes, as I've wrapped has_studio_advanced_settings_access in the new function I introduced, check_course_advanced_settings_access.

So, the check still happens if the AUTHZ_COURSE_AUTHORING_FLAG is not enabled. But, you bring up a good point that to keep existing functionality for the proctoring errors view, I would need to check DISABLE_ADVANCED_SETTINGS even if AUTHZ_COURSE_AUTHORING_FLAG is enabled.

I'm thinking through the permission check for the proctoring errors view. Right now this is how the permission check works:

has_studio_advanced_settings_access |---------------------------+-------+---------------------------------------| | DISABLE_ADVANCED_SETTINGS | not | result | |---------------------------+-------+---------------------------------------| | True | False | Only authorized if staff or superuser | | False | True | Authorized - no staff/superuser check | |---------------------------+-------+---------------------------------------|

The first thing to note here is that if DISABLE_ADVANCED_SETTINGS is False we don't do any further checks. I assume we would want to convert this scenario to check for the MANAGE_ADVANCED_SETTINGS permission, even though this wouldn't match current behavior?

Secondly, if DISABLE_ADVANCED_SETTINGS is True the current behavior is to make sure the user is staff or superuser to grant permission. If we migrate this check from solely staff/superuser to staff/superuser + role, then this changes behavior, as DISABLE_ADVANCED_SETTINGS is described as granting advanced settings access solely to staff/superusers.

new approach with openedx-authz |---------------------------+--------------------------------------------| | DISABLE_ADVANCED_SETTINGS | result | |---------------------------+--------------------------------------------| | True | Check MANAGE_ADVANCED_SETTINGS permission? | | False | Check MANAGE_ADVANCED_SETTINGS permission? | |---------------------------+--------------------------------------------|

Thoughts? @bmtcril @rodmgwgu

Mmm so the idea is that with MANAGE_ADVANCED_SETTINGS, we should be able to have the granularity to enable or disable advanced settings for specific users, so DISABLE_ADVANCED_SETTINGS won't be necessary anymore. I would vote then to only check for MANAGE_ADVANCED_SETTINGS if the flag is enabled.

bmtcril · 2026-02-17T13:53:09Z

common/djangoapps/student/auth.py

    )


+def check_course_advanced_settings_access(user, course_key, access_type='read'):


It seems like this is being used for more than just advanced settings checks, should it be renamed?

For the advanced settings page, the frontend calls the AdvancedCourseSettingsView (get/patch) and the ProctoringErrorsView (get). I wrapped all of those checks into this function. Since they are all advanced settings related, and since the ProctoringErrorsView check already called a function with "advanced settings" in the name, I thought this would be appropriate.

My first approach was to replace the current checks with something like:

if core_toggles.AUTHZ_COURSE_AUTHORING_FLAG.is_enabled(course_key): if not authz_api.is_user_allowed(user.username, MANAGE_ADVANCED_SETTINGS.identifier, str(course_key)): return self.permission_denied(request) elif not { current permission check }: return self.permission_denied(request)

but I didn't love the repetition, nesting, and having to import everything needed in both modules, so I wrapped all the checks.

bmtcril · 2026-02-17T13:54:46Z

common/djangoapps/student/auth.py

+        access_type: Type of access to check. Options:
+            - 'read': Check read access (default)
+            - 'write': Check write access
+            - 'advanced_settings': Check advanced settings access (DISABLE_ADVANCED_SETTINGS feature)


I don't think this comment is correct at this point?

Indirectly via has_studio_advanced_settings_access, but I agree this description could use some work.

Can we make the access_type option more descriptive? perhaps 'legacy_disable_advanced_settings_flag_check' or something like that?

bmtcril

Just a few comments to make sure I understand how this works with the DISABLE_ADVANCED_SETTINGS flag

rodmgwgu

Looking good, just some comments on active discussions.

rodmgwgu · 2026-02-17T21:56:33Z

common/djangoapps/student/auth.py

+        bool: True if user has permission, False otherwise
+    """
+    if core_toggles.AUTHZ_COURSE_AUTHORING_FLAG.is_enabled(course_key):
+        return authz_api.is_user_allowed(user.username, MANAGE_ADVANCED_SETTINGS.identifier, str(course_key))


Mmm so the idea is that with MANAGE_ADVANCED_SETTINGS, we should be able to have the granularity to enable or disable advanced settings for specific users, so DISABLE_ADVANCED_SETTINGS won't be necessary anymore. I would vote then to only check for MANAGE_ADVANCED_SETTINGS if the flag is enabled.

rodmgwgu · 2026-02-17T22:02:42Z

common/djangoapps/student/auth.py

+        access_type: Type of access to check. Options:
+            - 'read': Check read access (default)
+            - 'write': Check write access
+            - 'advanced_settings': Check advanced settings access (DISABLE_ADVANCED_SETTINGS feature)


Can we make the access_type option more descriptive? perhaps 'legacy_disable_advanced_settings_flag_check' or something like that?

openedx-webhooks added open-source-contribution PR author is not from Axim or 2U core contributor PR author is a Core Contributor (who may or may not have write access to this repo). labels Feb 13, 2026

openedx-webhooks added this to Contributions Feb 13, 2026

github-project-automation bot moved this to Needs Triage in Contributions Feb 13, 2026

wgu-taylor-payne added the mao-onboarding Reviewing this will help onboard devs from an Axim mission-aligned organization (MAO). label Feb 13, 2026

feat: authorize advanced settings endpoints via openedx-authz when fl…

007be04

…ag enabled

wgu-taylor-payne force-pushed the authz-authoring-advanced-settings branch from 6861d86 to 007be04 Compare February 13, 2026 23:36

fixup! feat: authorize advanced settings endpoints via openedx-authz …

c7d1cd0

…when flag enabled

wgu-taylor-payne requested review from bmtcril, dwong2708 and rodmgwgu February 14, 2026 00:42

bmtcril reviewed Feb 17, 2026

View reviewed changes

rodmgwgu reviewed Feb 17, 2026

View reviewed changes

		)


		def check_course_advanced_settings_access(user, course_key, access_type='read'):

Conversation

wgu-taylor-payne commented Feb 13, 2026

Description

Supporting information

Testing instructions

Deadline

Uh oh!

openedx-webhooks commented Feb 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wgu-taylor-payne Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmtcril left a comment

Choose a reason for hiding this comment

Uh oh!

rodmgwgu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wgu-taylor-payne Feb 17, 2026 •

edited

Loading