feat: extract overridable permission methods from ObjectTagView

[wgu-taylor-payne]

Extract overridable permission methods from ObjectTagView

Context

As part of the RBAC AuthZ course authoring milestone, edx-platform needs to substitute openedx-authz permission checks for the legacy django-rules checks on content tagging endpoints. The current ObjectTagView inlines its permission logic, forcing downstream overrides to duplicate significant parent view code — which is fragile and hard to maintain.

Changes

views.py — Extract 2 overridable access-control methods from ObjectTagView:

Method	Called from	Purpose
check_view_object_tags_permission(object_id, taxonomy)	get_queryset	Gate read access to object tags
check_can_tag_object_permission(object_id, taxonomy)	update	Gate write access

serializers.py — Extract 1 overridable method for response-field permission computation:

Method	Serializer	Purpose
get_can_tag_object(obj_tag)	ObjectTagsByTaxonomySerializer	Compute can_tag_object bool for response

ObjectTagMinimalSerializer.get_can_delete_objecttag was already overridable — no changes needed.

All default implementations preserve existing behavior exactly.

Design

Access-control checks (check_*) live on the view — they gate endpoint access from get_queryset and update. Response-field computation (get_can_tag_object, get_can_delete_objecttag) lives on the serializers, consistent with how all other permission fields (can_change_taxonomy, can_delete_tag, etc.) work in this package. This keeps a clean separation: views own access control, serializers own data representation.

Why

This lets downstream platforms (e.g., edx-platform) override permission logic without duplicating get_queryset, update, or retrieve code. The companion edx-platform PR is openedx/openedx-platform#38292.

Testing

• No behavior change for existing consumers — all existing tests pass without modification.
• Integration-tested via the companion edx-platform: PR feat: enforce openedx-authz permissions on object tag and xblock outline endpoints openedx-platform#38292.

Co-authored with Kiro

[openedx-webhooks]

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

This repository is currently maintained by @axim-engineering.

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 refactors the tagging REST API to make permission checks overridable in ObjectTagView, enabling downstream consumers (e.g., edx-platform) to swap legacy django-rules checks with openedx-authz without duplicating view logic.

Changes:

• Extracts 4 permission-related methods from ObjectTagView for downstream override.
• Updates serializers to delegate can_tag_object / can_delete_objecttag computation to the view methods when available in serializer context.
• Bumps repository version to 0.40.0.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/openedx_tagging/rest_api/v1/views.py	Adds overridable permission hooks and rewires get_queryset/update to call them.
src/openedx_tagging/rest_api/v1/serializers.py	Delegates permission-field computation to view methods (when present in serializer context).
src/openedx_core/__init__.py	Version bump.

---

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

[rodmgwgu]

Looks good, just a couple of nit comments. Thanks!

[wgu-taylor-payne]

I've updated openedx/openedx-platform#38292 to temporarily point to these changes until they are merged and released.

[ormsbee]

@wgu-taylor-payne: Can you please squash and update your commit message?

FYI to @jesperhodge, @mgwozdz-unicon, @bradenmacdonald, @tbain that this permissions refactoring is landing for tagging.

[wgu-taylor-payne]

@wgu-taylor-payne: Can you please squash and update your commit message?

@ormsbee I've squashed and updated the commit message.

[dwong2708]

LGTM. Thanks!

[ormsbee]

Sorry folks, I need to hold up this merge for a bit while I check with Axim folks on how to handle Kiro-assisted code. Our current policy accepts Copilot, Claude, and OpenAI. While Kiro largely delegates out to Claude, it does have some of its own models as well, and I need to check with our team and legal before I can merge this. Apologies for the delay.

I'm submitting this as "Request changes" even though there are no real changes to be made, just to indicate that it's not ready for merge at this time.