feat: use authz permission checks for tagging in course authoring

[wgu-taylor-payne]

Description

Use authz permission checks for tagging in course authoring when the AUTHZ_COURSE_AUTHORING_FLAG flag is enabled.

Object tag endpoint (/api/content_tagging/v1/object_tags/{object_id}/):

get_permissions() swaps legacy ObjectTagObjectPermissions for IsAuthenticated when authz is active. Non-course objects (libraries) fall through to legacy django-rules permissions.

GET:

Override	Layer	Authz behavior
ensure_has_view_object_tag_permission	View	Enforces courses.view_course
can_tag_object (ObjectTagOrgByTaxonomySerializer)	Serializer	Sets can_tag_object field value based on courses.manage_tags check
can_delete_object_tag (ObjectTagCopiedMinimalSerializer)	Serializer	Sets can_delete_objecttag field value based on courses.manage_tags check

PUT:

Override	Layer	Authz behavior
ensure_user_has_can_tag_object_permissions	View	Enforces courses.manage_tags

Xblock outline endpoint (/xblock/outline/{usage_key}):

This endpoint is called when the content tags drawer is opened in Studio (e.g. course outline, unit editor).

• GET — replaces has_studio_read_access with user_has_course_permission using courses.view_course, with legacy READ fallback when the flag is off.

Supporting information

Closes #38143.
Replaces: #38416 (auto-closed when base branch was merged).
Companion openedx-core PR: openedx/openedx-core#550.
Adjacent investigation into legacy permissions around tagging: #38222
Permission list: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5528715266/openedx-authz+permission+list

Testing instructions

Automated tests

pytest --ds=cms.envs.test \
openedx/core/djangoapps/content_tagging/rest_api/v1/tests/test_views.py::TestObjectTagOrgViewWithAuthz \
cms/djangoapps/contentstore/views/tests/test_block.py::TestXBlockOutlineHandlerAuthz

Manual tests

• Enable the authz.enable_course_authoring flag.
• Navigate to the course outline or block editor for a course where the flag is enabled.
• Global staff/superusers: can view outline, add/remove tags, see edit/delete controls on tags.
• Course staff role: can view outline, add/remove tags, see edit/delete controls on tags. Cannot tag other courses they don't have the role on.
• Course auditor role: can view outline and see existing tags (read-only). Cannot add/remove tags (403).

Deadline

Verawood

Other information

GitHub Copilot with Claude Sonnet 4 was used to aid development.

[openedx-webhooks]

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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.

[Copilot]

Pull request overview

This PR updates course authoring tagging endpoints to use openedx-authz permission checks (behind AUTHZ_COURSE_AUTHORING_FLAG) while retaining legacy permission behavior for non-course objects, and aligns CMS outline access with AuthZ.

Changes:

• Bump openedx-core to 0.45.0 and relax the corresponding constraints upper bound to <0.46.
• Add conditional AuthZ-based permission enforcement for object tagging (view/manage) and serializer permission fields.
• Switch xblock_outline_handler read-access checks to user_has_course_permission with legacy fallback when AuthZ is disabled, and add AuthZ-focused tests.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
requirements/edx/testing.txt	Bumps openedx-core pin to 0.45.0.
requirements/edx/doc.txt	Bumps openedx-core pin to 0.45.0.
requirements/edx/development.txt	Bumps openedx-core pin to 0.45.0.
requirements/edx/base.txt	Bumps openedx-core pin to 0.45.0.
requirements/constraints.txt	Allows openedx-core up to <0.46.
openedx/core/djangoapps/content_tagging/rest_api/v1/views.py	Adds AuthZ branching for course object tag view/manage permissions and permission classes.
openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py	Adds AuthZ-backed serializer permission computations for tagging/deleting.
openedx/core/djangoapps/content_tagging/auth.py	Adds helper to determine whether to use AuthZ for a given object id/context.
openedx/core/djangoapps/content_tagging/rest_api/v1/tests/test_views.py	Adds AuthZ tests for object tag endpoints and updates query-count expectations.
cms/djangoapps/contentstore/views/tests/test_block.py	Adds AuthZ tests for outline handler access.
cms/djangoapps/contentstore/views/block.py	Uses AuthZ permission check for outline handler, with legacy fallback when AuthZ is disabled.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dwong2708]

LGTM! Thanks.

[rodmgwgu]

Looks good, tested in local and working correctly. Thanks!

[MaferMazu]

Hello @wgu-taylor-payne, thanks for this PR ✨

✅ Regarding the behavior, it works as expected.
I encountered a small, unexpected behavior and want to confirm whether it was on the radar.

• If an Admin or someone with permissions applies a Tag over a course, and there is another user with less permission, but with manage_tags, it doesn't necesary means that this second user can see the tag.

How to replicate it:

• An admin user creates a Taxonomy and applies it to a course.
• Log in as a Course Editor to that course, and you aren't able to see the Tag (unless the Taxonomy is configured to all orgs).

I think it's because we are filtering the taxonomies based on permissions as well.
Are we okay with the behavior?

# Course Editor Response of api/content_tagging/v1/object_tags/course-v1:OpenedX+DemoX+DemoCourse/
{"course-v1:OpenedX+DemoX+DemoCourse":{"taxonomies":[]}}

# Admin Response of api/content_tagging/v1/object_tags/course-v1:OpenedX+DemoX+DemoCourse/
{
    "course-v1:OpenedX+DemoX+DemoCourse": {
        "taxonomies": [
            {
                "name": "School Topics",
                "taxonomy_id": 1,
                "can_tag_object": true,
                "tags": [
                    {
                        "value": "Humanities",
                        "lineage": [
                            "Humanities"
                        ],
                        "can_delete_objecttag": true,
                        "is_copied": false
                    }
                ],
                "export_id": "2-school-topics"
            }
        ]
    }
}

Apart from that, I think we should add a bit about adding the outline enforcement points to the PR title and description. I noticed you added something in #38292, but it's not in this new version.

[wgu-taylor-payne]

@MaferMazu Thanks for the review!

I think it's because we are filtering the taxonomies based on permissions as well. Are we okay with the behavior?

Good catch. I've updated the filter so that if authz is active and we are dealing with a course, the user can see tags from global level taxonomies and from taxonomies of the org that the course is a part of. I've added a test for your scenario, but haven't had the chance to manually test yet in my local.

Apart from that, I think we should add a bit about adding the outline enforcement points to the PR title and description.

I've updated the description. Since the xblock outline endpoint is called in associated with the manage tags drawer, I think the PR title is a good umbrella for the changes in this PR.

[MaferMazu]

✨ Thanks for addressing my comments. Now, a course team member can see the tags applied to the course.

But that made me realize two things:

• A course auditor can see the option to manage tags when they can't manage tags. This is a no-blocker at all. I recommend creating a nice-to-have issue about it and fixing it after the cut.
• A course editor, that supose to be able to modify tags, can't. (The api may be working correctly, but in the interface, they are not able to select the tag to add or delete.)

Screencast.from.2026-04-28.17-42-58.webm

Note: regarding the last thing, I managed to delete tags, but I'm not able to add them back or add new ones (despite the taxonomy being available for the course org). I think it is related to the permissions in the taxonomy itself (something like what happened with the filter)

We can handle this in this or another PR, but to comply with tag permissions, we should address it. What do you think @wgu-taylor-payne?

[wgu-taylor-payne]

@MaferMazu

• A course auditor can see the option to manage tags when they can't manage tags. This is a no-blocker at all. I recommend creating a nice-to-have issue about it and fixing it after the cut.

I've added openedx/frontend-app-authoring#3036 that captures this issue, and is also a catch-all, to make sure the UI for managing tags is synced with the authz changes we've introduced.

Also, FYI, I've also added an issue for what still needs to be done with taxonomies on the backend: #38470.

• A course editor, that supose to be able to modify tags, can't. (The api may be working correctly, but in the interface, they are not able to select the tag to add or delete.)

Editing courses is working in my local with course editor

I tried with both global taxonomy and a taxonomy scoped to the course org. Here are the screenshots when I tagged with the global taxonomy -

Course Editor as seen in admin console:

I add the Humanities tag:

I press Save:

Toast shows added:

Refresh the page and Humanities is still there:

[MaferMazu]

Thanks for answering my feedback @wgu-taylor-payne ✨

I couldn't replicate the tag sidebar behavior, likely because I don't have the latest version of authoring. But as the api works as expected, this PR looks good.