feat(taxonomy): add taxonomy type selection to import tags wizard

[javoconsultant]

Description

openedx/openedx-core#615

Recording.at.2026-08-27.02.29.27.mp4

Supporting information

openedx/openedx-core#615

Testing instructions

• Log in to Studio as an Admin or Staff user.
• Click on the Taxonomies tab.
• Click the Import button.
• Upload a JSON or CSV file in the required template format.
• Click Continue.
• The modal advances to a "Populate Taxonomy Information" step with 3 fields: Taxonomy Nam, Taxonomy Description and Taxonomy Type (new field)

Other information

This PR is stuck in draft, blocked by openedx/openedx-core#614

Best Practices Checklist

We're trying to move away from some deprecated patterns in this codebase. Please
check if your PR meets these recommendations before asking for a review:

• Any new files are using TypeScript (.ts, .tsx).
• Avoid propTypes and defaultProps in any new or modified code.
• Tests should use the helpers in src/testUtils.tsx (specifically initializeMocks)
• Do not add new fields to the Redux state/store. Use React Context to share state among multiple components.
• Use React Query to load data from REST APIs. See any apiHooks.ts in this repo for examples.
• All new i18n messages in messages.ts files have a description for translators to use.
• Avoid using ../ in import paths. To import from parent folders, use @src, e.g. import { initializeMocks } from '@src/testUtils'; instead of from '../../../../testUtils'

[openedx-webhooks]

Thanks for the pull request, @javoconsultant!

This repository is currently maintained by @bradenmacdonald.

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.

[mphilbrick211]

Hi @javoconsultant!

Welcome, and thank you for this contribution! In order for your CLA check to turn green, you'll need to submit a CLA form. If you are contributing as an individual, please fill out the individual CLA form here.

If you are contributing on behalf of an organization, please have your manager reach out to oscm@axim.org so you may be added to your org's existing entity agreement.

Please let me know if you have any questions. Thanks!

[mphilbrick211]

@javoconsultant when you have a moment, please also add a description of your changes to the top of this pull request. Thank you!

[javoconsultant]

@javoconsultant when you have a moment, please also add a description of your changes to the top of this pull request. Thank you!

Hi @mphilbrick211, I've modified description

[mgwozdz-unicon]

Claude and I worked together on this code review and came up with the following items:

1. Consider a native Form.Control as="select" instead of SelectMenu for the Taxonomy Type field.

In this codebase, SelectMenu is the established pattern for transient filter or action menus, like the org filter on TaxonomyListPage.tsx, not for a value that lives in form state and gets submitted with a mutation. Form.Control as="select" is that pattern, it's used throughout the app and by the Name and Description fields already in this same file, and it gets label association for free from Form.Group. The current implementation has to hand-wire id/aria-labelledby instead, renders each option as a link rather than an option (confirmed by the test's own getByRole('link') queries), and gives the user no visual indication of which option is currently selected when the menu is open. A native select would resolve all of that at once.

2. TaxonomyType is imported from a feature folder into the shared data layer.

src/taxonomy/data/apiHooks.ts imports TaxonomyType from ../import-tags/constants, which inverts the usual dependency direction, the generic taxonomy data layer now depends on one specific wizard's constants file. It's really a domain and API concept, since it goes straight into the FormData payload, so it belongs in src/taxonomy/data/types.ts or a new data/constants.ts instead. The ticket that will later display the taxonomy type elsewhere will need this same enum outside the import wizard, so worth fixing the direction now rather than later.

3. Please add a test for the default "Tags" path reaching the API, and consider splitting the dropdown test out.

apiHooks.test.jsx covers both TaxonomyType values reaching the FormData at the hook level, but the full wizard test in ImportTagsWizard.test.jsx only asserts the payload for the explicit "Competency" selection.

• Please add a case for leaving the dropdown at its default ("Tags") and asserting that reaches the API too.
• Please add a test for keyboard-only interaction: opening the menu, arrow-navigating between options, and closing it. A custom menu doesn't get that from the browser the way a native select would.
• Consider pulling the dropdown's own behavior into its own smaller test rather than folding it into the large parametrized wizard test, that would make failures easier to isolate going forward.

4. A few smaller items.

• The three new i18n messages in messages.ts don't include a description for translators (the rest of the file doesn't either, but worth not compounding it). Suggested text:
  • importWizardStepPopulateTaxonomyType: "Label for the dropdown where the user selects the type of taxonomy being imported."
  • importWizardStepPopulateTaxonomyTypeTags: "Option in the Taxonomy Type dropdown for a standard tag taxonomy."
  • importWizardStepPopulateTaxonomyTypeCompetency: "Option in the Taxonomy Type dropdown for a competency taxonomy."
• It'd help future readers to add a short comment on TAXONOMY_TYPE_OPTIONS in constants.ts explaining what actually distinguishes the two types: a Tags taxonomy is just a label for content with no rules for demonstrating mastery, while a Competency taxonomy is a taxonomy of skills and enables the Competency Management page for configuring the rules used to demonstrate mastery of them.
• The new tests still call initializeMockApp rather than initializeMocks from testUtils.tsx.
• PopulateStep.propTypes gains a new PropTypes.oneOf(...) entry, which the checklist asks to avoid in modified code.

5. Please fill out the rest of the PR description.

Only the Description section is filled in (the video and the link to #615), the rest, including Testing instructions, Other information, and the Best Practices Checklist, is still placeholder text. Since this is still a draft PR, could you also note here that it depends on #614 (import endpoint support for taxonomy_type) before it can come out of draft and be verified end to end?

[codecov]

Codecov Report

❌ Patch coverage is 99.41176% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.93%. Comparing base (16e19f1) to head (03087d0).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
src/taxonomy/import-tags/steps/UploadStep.tsx	96.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3208   +/-   ##
=======================================
  Coverage   95.92%   95.93%           
=======================================
  Files        1397     1403    +6     
  Lines       33581    33640   +59     
  Branches     7947     7962   +15     
=======================================
+ Hits        32214    32273   +59     
- Misses       1308     1309    +1     
+ Partials       59       58    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mgwozdz-unicon]

Thanks for the updates in the latest commit. Here's where the earlier review items stand.

Done:

• Item 1 (native select): PopulateStep.tsx now uses Form.Control as="select" inside a Form.Group/Form.Label, so the label association is automatic and the options render as real <option> elements.
• Item 2 (dependency direction): TaxonomyType now lives in src/taxonomy/data/constants.ts, and both apiHooks.ts and the import-tags feature import it from there instead of the other way around.
• The PopulateStep.propTypes concern from item 4 is moot now that the file has been converted to TypeScript and no longer uses propTypes at all.

Still open:

• Item 3: the wizard-level test in ImportTagsWizard.test.tsx ("can upload new taxonomies from the dialog") still only exercises the explicit "Competency" selection and asserts taxonomy_type=competency in the posted FormData. Could you add a case that leaves the dropdown at its default ("Tags") and asserts taxonomy_type=tags reaches the API the same way? (apiHooks.test.jsx was updated to loop over both TaxonomyType values, but that's the hook-level test, not the wizard test this item was about.) The keyboard-only interaction test (open the dropdown, arrow between options, close it) and splitting the dropdown assertions out of the large parametrized test are both still outstanding too.
• Item 4: the three new i18n messages (importWizardStepPopulateTaxonomyType, importWizardStepPopulateTaxonomyTypeTags, importWizardStepPopulateTaxonomyTypeCompetency) still don't have a description for translators. The suggested text from the earlier review still applies:
  • importWizardStepPopulateTaxonomyType: "Label for the dropdown where the user selects the type of taxonomy being imported."
  • importWizardStepPopulateTaxonomyTypeTags: "Option in the Taxonomy Type dropdown for a standard tag taxonomy."
  • importWizardStepPopulateTaxonomyTypeCompetency: "Option in the Taxonomy Type dropdown for a competency taxonomy."
• TAXONOMY_TYPE_OPTIONS in steps/constants.ts has a docstring now, but it doesn't explain what actually distinguishes the two types. Worth adding: a Tags taxonomy is just a label for content with no rules for demonstrating mastery, while a Competency taxonomy is a taxonomy of skills and enables the Competency Management page for configuring the rules used to demonstrate mastery of them.
• ImportTagsWizard.test.tsx, where the new dropdown tests live, still sets up its mocks with initializeMockApp and a manually constructed MockAdapter in beforeEach, rather than initializeMocks from testUtils.tsx.
• Item 5: Testing instructions are filled in now, but Other information is still the placeholder text, the Best Practices Checklist is still fully unchecked, and there's no note that this depends on #614 (import endpoint support for taxonomy_type) before it can come out of draft and be verified end to end.

[mgwozdz-unicon]

Thank you for addressing the rest of those items! I'm approving, but could you please still update the Description so that the Other Information section mentions that this PR is stuck in draft blocked by openedx-core#614 and check the boxes in the Best Practices section?

[javoconsultant]

Thank you for addressing the rest of those items! I'm approving, but could you please still update the Description so that the Other Information section mentions that this PR is stuck in draft blocked by openedx-core#614 and check the boxes in the Best Practices section?

@mgwozdz-unicon done! thank you