feat: new AuthZ permissions for import/export courses and export tags by rodmgwgu · Pull Request #38173 · openedx/openedx-platform

rodmgwgu · 2026-03-13T22:52:28Z

Description

Implement new AuthZ permission checks over endpoints related with import/export courses functionality, and export tags from courses.

The new AuthZ permission checks only apply when the enable_authz_course_authoring feature flag is enabled for the specific course, or globally, otherwise existing behavior persist.

The following AuthZ permissions are being used:

courses.import_course
courses.export_course
courses.export_tags

The following endpoints were updated:

GET /export_status/(course_id) Permission: courses.export_course
POST /export/(course_id) Permission: courses.export_course
GET /export_output/(course_id) Permission: courses.export_course
GET /import_status/(course_id) Permission: courses.import_course
POST /import/(course_id) Permission: courses.import_course
GET /api/content_tagging/v1/object_tags/(course_id)/export/ Permission: courses.export_tags

Also updated tests and existing test utilities for being more flexible to test AuthZ use cases across the codebase.

Supporting information

Closes openedx/openedx-authz#201

Testing

Verified that:

Authorized users can access the endpoints.
Unauthorized users receive a 403 response.
Legacy permission fallback works as expected.

Running relevant tests manually:

On a cms container (run with tutor dev exec cms bash), do:

pytest -p no:randomly --ds=cms.envs.test openedx/core/djangoapps/content_tagging/rest_api/v1/tests/test_views.py

pytest -p no:randomly --ds=cms.envs.test cms/djangoapps/contentstore/views/tests/test_import_export.py

Deadline

Verawood

Other information

Depends on #38156

openedx-webhooks · 2026-03-13T22:52:33Z

Thanks for the pull request, @rodmgwgu!

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.

rodmgwgu · 2026-03-18T19:17:27Z

openedx/core/djangoapps/content_tagging/rest_api/v1/urls.py

    path(
        "object_tags/<str:context_id>/export/",
        views.ObjectTagExportView.as_view(),
+        name="taxonomy-object-tag-export",


Named this so we can refer to it on tests with the reverse method.

rodmgwgu · 2026-03-18T19:19:15Z

openedx/core/djangoapps/content_tagging/auth.py

+    except InvalidKeyError:
+        log.warning("Invalid course key %s", object_id)
+
+    if course_key and core_toggles.enable_authz_course_authoring(course_key) and not authz_api.is_user_allowed(


I'm still letting the old checks (line 35) to run even when the authz check gets done, as these are different from the rest of the course authoring checks and I'm not familiar with this logic.

@bmtcril are you familiar with this?

I put this comment in the wrong line, I'm referring to the checks on line 35

I know roughly what it is: https://github.com/dfunckt/django-rules but I'm not familiar with our implementation for tagging. I'll ask around to see if anyone else here knows more.

Maybe this can help? https://github.com/openedx/openedx-platform/pull/38071/changes#diff-15db056809a5257a6081c33072c7d430098eb751b7bea826c8e1325702b4c9c4

It's the implementation we did for library tags, maybe something we learned there can be reused here FYI @BryanttV

What I can add here is that user.has_perm() in this case calls the functions can_view_object_tag_taxonomy and can_view_object_tag_objectid, but since taxonomy=None, it only goes into the validation in the second function. There, it checks whether the user has read permissions in Studio, or if the user is an org_admin or org_user. I’m not sure whether we want to keep that legacy validation or remove it and simply rely on authz.

@BryanttV what defines org_admin and org_user?

@bmtcril

org_admin verifies whether the user has the OrgStaffRole within a specific organization.

org_user verifies whether the user has roles at the organization level (OrgLibraryUserRole, OrgInstructorRole, OrgContentCreatorRole), course level (CourseStaffRole, CourseInstructorRole), or library level.

I think it’s best to maintain the legacy validation since, as Rodrigo mentions, has_view_object_tags_access doesn’t only check permissions for a course.

I would lean towards returning the result of is_user_allowed if we know we have a course key here and the flag is enabled.

cms/djangoapps/contentstore/views/tests/test_import_export.py

openedx/core/djangoapps/content_tagging/rest_api/v1/tests/test_views.py

dwong2708 · 2026-03-19T17:56:33Z

openedx/core/djangoapps/content_tagging/auth.py

+    try:
+        course_key = CourseKey.from_string(object_id)
+    except InvalidKeyError:
+        log.warning("Invalid course key %s", object_id)


Should we re-raise this exception? The logic below depends on it, and not doing so might cause silent errors

So my though process here was:

I see that this function can be used for things other than courses, so in that case we don't want to affect the existing behavior.

So, if CourseKey.from_string fails, course_key will remain None

Then when we get to the if, because course_key is None, we don't validate for Authz

This means that we fallback to the code below that is the old validation check.

I added a comment to clarify this

wgu-taylor-payne · 2026-03-24T19:58:08Z

openedx/core/djangoapps/content_tagging/auth.py

+    try:
+        course_key = CourseKey.from_string(object_id)
+    except InvalidKeyError:
+        log.warning("Invalid course key %s", object_id)


Since non-course ids are a valid case, I think logging a warning wouldn't be appropriate. I would downgrade to debug or swap the logging statement with pass.

wgu-taylor-payne · 2026-03-24T22:27:38Z

cms/djangoapps/contentstore/views/tests/test_import_export.py

+    def test_superuser_allowed(
+        self,
+        mock_get_user_task_artifact,
+        mock_latest_task_status,
+        mock_storage,
+    ):


The decorators are applied from the bottom up, so the params should be in this order:

Suggested change

def test_superuser_allowed(

self,

mock_get_user_task_artifact,

mock_latest_task_status,

mock_storage,

):

def test_superuser_allowed(

self,

mock_storage,

mock_latest_task_status,

mock_get_user_task_artifact,

):

wgu-taylor-payne · 2026-03-24T22:43:57Z

openedx/core/djangoapps/content_tagging/auth.py

+
+

Remove one of the blank lines here.

Suggested change

wgu-taylor-payne · 2026-03-24T22:57:52Z

openedx/core/djangoapps/authz/tests/mixins.py

+        self.authorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()
+        self.unauthorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()


I like the idea of setting password = 'test' as an attribute on the mixin and then always created the users with self.password:

Suggested change

self.authorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()

self.unauthorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()

self.authorized_user = UserFactory(password=self.password)

self.unauthorized_user = UserFactory(password=self.password)

wgu-taylor-payne · 2026-03-25T00:55:07Z

openedx/core/djangoapps/content_tagging/auth.py

+    except InvalidKeyError:
+        log.warning("Invalid course key %s", object_id)
+
+    if course_key and core_toggles.enable_authz_course_authoring(course_key) and not authz_api.is_user_allowed(


I would lean towards returning the result of is_user_allowed if we know we have a course key here and the flag is enabled.

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 Mar 13, 2026

openedx-webhooks added this to Contributions Mar 13, 2026

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

mphilbrick211 added the mao-onboarding Reviewing this will help onboard devs from an Axim mission-aligned organization (MAO). label Mar 17, 2026

mphilbrick211 moved this from Needs Triage to Waiting on Author in Contributions Mar 17, 2026

rodmgwgu force-pushed the rod/new-permissions-importexport branch 2 times, most recently from 8531587 to 4208e9d Compare March 18, 2026 18:50

rodmgwgu commented Mar 18, 2026

View reviewed changes

rodmgwgu requested review from BryanttV, bmtcril, dwong2708, mariajgrimaldi and wgu-taylor-payne March 18, 2026 19:19

rodmgwgu marked this pull request as ready for review March 18, 2026 19:20

dwong2708 suggested changes Mar 19, 2026

View reviewed changes

rodmgwgu force-pushed the rod/new-permissions-importexport branch from 4208e9d to 5513880 Compare March 20, 2026 21:54

rodmgwgu added 5 commits March 24, 2026 11:26

feat: New Authz checks on import and export endpoints

4600d88

squash!: Add tests for user without permissions

10b3fd7

squash!: Add comment clarifying has_view_object_tags_access logic

9852985

squash!: Fix comment

fd9a9d8

squash!: Simplify CourseAuthoringAuthzTestMixin change

9776759

rodmgwgu force-pushed the rod/new-permissions-importexport branch from 85ba7a2 to 9776759 Compare March 24, 2026 17:27

squash!: Avoid breaking existing tests

66c0a37

wgu-taylor-payne reviewed Mar 25, 2026

View reviewed changes

		self.authorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()
		self.unauthorized_user = UserFactory(password=self.password) if hasattr(self, 'password') else UserFactory()

Conversation

rodmgwgu commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Supporting information

Testing

Deadline

Other information

Uh oh!

openedx-webhooks commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rodmgwgu Mar 18, 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!

mariajgrimaldi Mar 19, 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

rodmgwgu commented Mar 13, 2026 •

edited

Loading

openedx-webhooks commented Mar 13, 2026 •

edited

Loading

rodmgwgu Mar 18, 2026 •

edited

Loading

mariajgrimaldi Mar 19, 2026 •

edited

Loading