feat: add taxonomy_type to TaxonomyOrgView

[alezconsultant]

Description

TaxonomyOrgView now dispatches taxonomy_type itself, calling create_taxonomy() or
create_competency_taxonomy() directly depending on the value, instead of subclassing a
CBE-owned view. Implements the acceptance criteria from openedx/openedx-core#614.

Changes

• TaxonomyOrgView subclasses TaxonomyView (from openedx_tagging) directly.
• perform_create(): branches on taxonomy_type. "competency" calls
  create_competency_taxonomy(), wrapped in the same try/except the base class uses
  around create_taxonomy(), so a validation failure (e.g. duplicate export_id) 400s
  on both paths instead of 500ing on only one. Anything else defers to
  super().perform_create().
• _create_taxonomy_for_import(): same dispatch for the import path.
• create_import(): unchanged. It already calls super().create_import(), which
  now routes through this override via normal virtual dispatch.

Tests

Seven test methods, one per #614 Given/When/Then scenario: creating and importing a
competency taxonomy (asserting the CompetencyTaxonomy row exists), creating and
importing with "tags" or no taxonomy_type (asserting it doesn't), and rejecting
an unsupported value on both endpoints. Plus a regression test for the duplicate
export_id case the try/except protects against.

Manual testing instructions

To be able to test this PR locally you need to work with local version of openedx-core.
This PR depends on openedx-core#803 (taxonomy_type support, create_competency_taxonomy()), mount a local openedx-core checkout with that work instead ( or pin 1.4.0 ver).

1. Mount openedx-core:

   tutor dev stop
   git clone https://github.com/openedx/openedx-core.git
   cd openedx-core && git checkout main
   cd ..
   tutor mounts add ./openedx-core
   tutor images build openedx-dev
   tutor dev launch
   

2. Check out this PR's branch and restart Studio:

   tutor dev restart lms cms
   

3. I asked claude to wrote a curl based script (with all cases)
   that captures coockies and CSRF tokens needed for the requests so I don't copy requests from developer tools every time (which should also work and for non default/tags requests testing can be done via ui):

   COOKIES=/tmp/lms_cookies.txt; rm -f "$COOKIES"
   curl -s -c "$COOKIES" "http://local.openedx.io:8000/login" -o /dev/null
   CSRFTOKEN=$(grep csrftoken "$COOKIES" | awk '{print $NF}')
   curl -s -b "$COOKIES" -c "$COOKIES" -H "X-CSRFToken: $CSRFTOKEN" -H "Referer: http://local.openedx.io:8000/login" --data-urlencode "email=test@test.com" --data-urlencode "password=test" "http://local.openedx.io:8000/api/user/v1/account/login_session/" -o /dev/null -w "login status: %{http_code}\n"
   AUTH_HEADER="Authorization: JWT $(grep "edx-jwt-cookie-header-payload" "$COOKIES" | awk '{print $NF}').$(grep "edx-jwt-cookie-signature" "$COOKIES" | awk '{print $NF}')"
   CMS_URL="http://studio.local.openedx.io:8001"

4. Then I use curl (Postman is fine too) to run all cases:

   Create, taxonomy_type=competency — expect 201:

   curl -s -H "$AUTH_HEADER" -H "Content-Type: application/json" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/" -d '{"name": "Test Competency", "description": "test", "taxonomy_type": "competency"}'

5. Create, taxonomy_type=tags — expect 201, no CompetencyTaxonomy row:

   curl -s -H "$AUTH_HEADER" -H "Content-Type: application/json" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/" -d '{"name": "Test Tags", "description": "test", "taxonomy_type": "tags"}'

6. Create, no taxonomy_type — expect 201, no CompetencyTaxonomy row (same as "tags"):

   curl -s -H "$AUTH_HEADER" -H "Content-Type: application/json" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/" -d '{"name": "Test Default", "description": "test"}'

7. Create, taxonomy_type=system (unsupported) — expect 400, taxonomy_type named in the response body:

   curl -s -H "$AUTH_HEADER" -H "Content-Type: application/json" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/" -d '{"name": "Test Test Rejected", "taxonomy_type": "system"}' -w "\nstatus: %{http_code}\n"

8. Import, taxonomy_type=competency — expect 201:

   echo '{"tags": [{"id": "tag_1", "value": "Tag 1"}]}' > ./test_tags.json
   curl -s -H "$AUTH_HEADER" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/import/" -F "taxonomy_name=Test Import Competency" -F "taxonomy_description=test" -F "taxonomy_type=competency" -F "file=@./test_tags.json;type=application/json"

9. Import, no taxonomy_type — expect 201:

   curl -s -H "$AUTH_HEADER" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/import/" -F "taxonomy_name=Test Import Default" -F "taxonomy_description=test" -F "file=@./test_tags.json;type=application/json"

10. Import, taxonomy_type=system — expect 400:

    curl -s -H "$AUTH_HEADER" -X POST "$CMS_URL/api/content_tagging/v1/taxonomies/import/" -F "taxonomy_name=Test Import Rejected" -F "taxonomy_description=test" -F "taxonomy_type=system" -F "file=@./test_tags.json;type=application/json" -w "\nstatus: %{http_code}\n"

11. After each query confirm that CompetencyTaxonomy records appears or omitted in mysql tables.

Related to openedx/openedx-core#614
Dependent on openedx/openedx-core#803

🤖 Generated with help of Claude Code

[openedx-webhooks]

Thanks for the pull request, @alezconsultant!

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

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.

[mgwozdz-unicon]

This looks good to me, pending a green build once openedx-core is released with a new version after openedx/openedx-core#803 merges. Can you please update the description of this PR to indicate that it's dependent on openedx/openedx-core#803 and switch this PR to Draft until openedx/openedx-core#803 merges?

[alezconsultant]

Done.
Converted to draft until openedx-core merged.

[kdmccormick]

Just one request, looks good otherwise.

Did you manually test this? Please describe how you manually tested in the PR description.

Lastly, please make sure you've read the contributor requirements in our AI Policy.

Thanks!

[kdmccormick]

Thanks for using type annotations!

[kdmccormick]

This class's docstring says: This view extends the TaxonomyView to add Organization filters. With this PR's change, TaxonomyOrgView will now also be responsible for switching between create_taxonomy and create_competency_taxonomy.

Can you update the docstring to reflect the increased scope of responsibility?

[alezconsultant]

@kdmccormick I try to consistently add Claude as a co-author to commits where I use its assistance. After your notification, I also added a clarification to the pr description thanks for pointing that out. I also updated the docstring for TaxonomyOrgView. As for manual testing, yes, I did it with claude's help. It helped me write a curl-based script that I can reuse in the future, so I don't have to manually copy requests, cookies, and the csrf token from the browser dev tools. I've added the testing instructions to the PR description.. Postman should work as well, but for now I'm using the curl-based approach.

[kdmccormick]

Looks great, thanks!

[alezconsultant]

I should've squash it.

[kdmccormick]

That's OK @alezconsultant , if you put a good commit message in your PR description, then we can just squash while merging and use that as the commit message body.

[alezconsultant]

@kdmccormick update PR description with commit message.

[kdmccormick]

@alezconsultant sorry, I don't understand what you mean.

[alezconsultant]

@kdmccormick My bad, thought i need to manually squash it locally before merge to update squash message, but as you said it's alright, misunderstanding from my side.