feat: authorize tags and taxonomies endpoints via openedx-authz when …

[wgu-taylor-payne]

Description

Adds openedx-authz permission checks (courses.manage_tags and courses.manage_taxonomies) to all content tagging API endpoints, behind the existing AUTHZ_COURSE_AUTHORING_FLAG feature flag. When the flag is off, behavior is unchanged — all endpoints use the existing legacy django-rules permission checks.

Key design decisions:

• Non-course-scoped taxonomy endpoints (e.g., GET /taxonomies/, DELETE /taxonomies/{id}/, POST /taxonomies/import/) check the flag globally via AUTHZ_COURSE_AUTHORING_FLAG.is_enabled() with no course_key. This means authz only activates for these endpoints when the flag is enabled for everyone — not when it's enabled for a single course via override.

• Course-scoped object_tags endpoints (PUT /object_tags/{course_id}/) check the flag per-course via AUTHZ_COURSE_AUTHORING_FLAG.is_enabled(course_key), respecting course and org overrides.

• For non-course-scoped authz checks, we use get_scopes_for_user_and_permission() to verify the user has the permission in any scope, since there's no specific course_key to check against. This aligns with the Casbin policy where course_staff has manage_tags for course-v1^* and course_admin has manage_taxonomies for course-v1^*.

• When authz is globally enabled, TaxonomyOrgView.get_permissions() replaces the parent's DjangoObjectPermissions with IsAuthenticated. This prevents the legacy permission classes from blocking users who are authorized via authz but don't have legacy roles.

• Serializer permission fields (can_change_taxonomy, can_delete_taxonomy, can_tag_object) are overridden in TaxonomyOrgSerializer to be authz-aware when the flag is on, and delegate to the parent's cached _can() path when the flag is off. This means the frontend adapts automatically — no frontend changes needed.

Impacted user roles: Course Author, Operator (anyone managing taxonomies/tags in Studio).

Endpoint → permission mapping:

Endpoint	Permission	Flag scope
PUT /taxonomies/{id}/orgs/	courses.manage_taxonomies	global
DELETE /taxonomies/{id}/	courses.manage_taxonomies	global
GET /taxonomies/{id}/export/	courses.manage_taxonomies	global
POST /taxonomies/import/	courses.manage_taxonomies	global
PUT /taxonomies/{id}/tags/import/plan/	courses.manage_taxonomies	global
PUT /taxonomies/{id}/tags/import/	courses.manage_tags	global
PUT /object_tags/{course_id}/	courses.manage_tags	per-course
GET /object_tags/{course_id}/export/	courses.export_tags (existing)	per-course

Supporting information

• Closes Task - RBAC Authz - Implement new permissions for Tags and Taxonomies #38143
• Permission list: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5528715266/openedx-authz+permission+list

Testing instructions

Flag OFF (legacy behavior unchanged):

1. Ensure authz.enable_course_authoring waffle flag is inactive
2. As a staff user, verify all taxonomy CRUD operations work as before
3. As a course staff user, verify tagging content objects works as before

Flag ON globally (taxonomy management):

1. Django Admin → Waffle Flags → authz.enable_course_authoring → set "Everyone" to Yes
2. Seed authz policies (or ensure migration has run)
3. As a user with course_admin authz role: verify delete taxonomy, update orgs, import/export all return 200/201/204
4. As a user with no authz role: verify the same operations return 403
5. GET /taxonomies/ should return can_change_taxonomy: true/false and can_delete_taxonomy: true/false matching the user's authz permissions

Flag ON per-course (object tags):

1. Add a course override: Django Admin → Waffle Flag Course Overrides → authz.enable_course_authoring for a specific course → Force On
2. As a user with course_staff authz role for that course: PUT /object_tags/{course_id}/ should succeed
3. As a user without the role: should return 403
4. For a different course without the override: should fall through to legacy checks

Deadline

Verawood

Other information

• Pre-existing test issue: TestTaxonomyTagsViewSet::test_taxonomy_tags_query_count has a query count mismatch that exists on master before this PR. Not caused by these changes.
• Policy note: Per the authz policy file, course_admin has both manage_tags and manage_taxonomies, while course_staff only has manage_tags. This means only course admins can manage taxonomies (create/delete/import/export/manage orgs), while course staff can manage tags (tag objects, import tags into existing taxonomies).
• Co-authored with Kiro — AI-assisted implementation and testing.

[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.

🔘 Update the status of your PR

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

• 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.