Repository navigation
[FE] Add taxonomy type badge to Taxonomies page #616
Description
Use Case
As a Platform Administrator, I need to see a taxonomy type badge on each taxonomy card on the Taxonomies page so that I can quickly distinguish Competency Taxonomies from standard tag taxonomies at a glance without leaving the page.
Description
This issue updates every taxonomy card to always display exactly one type badge:
- "Competency" — new badge for Competency Taxonomies, visually distinct color from System-level
- "Tags" — new badge for standard tag taxonomies
The badge is determined by thetaxonomyType field being added to the API response (added by #618). The priority order is:
- If
taxonomyTypeis"competency"→ show "Competency" badge - Otherwise → show "Tags" badge
This ticket is the display counterpart to the import dropdown added in #615 and removes the need for Postman verification of taxonomy type after import.
Dependency: Requires #618 (GET endpoint returning taxonomy_type) and #630 (verifies TaxonomyOrgSerializer in edx-platform passes taxonomy_type through in the /api/content_tagging/v1/taxonomies/ response) to be merged first.
Acceptance Criteria
Scenario 1: Competency taxonomy shows Competency badge
Given a Competency Taxonomy exists on the platform
When I navigate to the Taxonomies page
Then the taxonomy card displays a "Competency" icon
Scenario 2: Standard tag taxonomy shows Tags badge
Given a standard tag taxonomy exists on the platform
When I navigate to the Taxonomies page
Then the taxonomy card displays a "Tags" icon
Scenario 3: Every taxonomy card shows exactly one type badge
Given multiple taxonomies of different types exist on the platform
When I navigate to the Taxonomies page
Then each taxonomy card displays exactly one type icon
And no taxonomy card displays more than one type icon
UX Designs
Technical Notes
Note that this section was drafted before the system taxonomy type was removed. Ignore anything below related to the system type taxonomy.
Files to Create
| File | Purpose |
|---|---|
src/taxonomy/taxonomy-card/TaxonomyTypeBadge.jsx |
New badge component that accepts systemDefined and taxonomyType props and renders the correct label and color |
Modified Files
| File | Nature of modification |
|---|---|
src/taxonomy/data/types.ts |
Add `taxonomyType: 'competency' |
src/taxonomy/taxonomy-card/index.jsx |
Replace conditional SystemDefinedBadge rendering (lines 122–128) with TaxonomyTypeBadge, passing both systemDefined and taxonomyType |
Implementation Notes
taxonomyTypeis not yet in the frontend data layer. AddtaxonomyType: 'competency' | 'tags'to theTaxonomyDatainterface intypes.ts(lines 2–18). ThecamelCaseObject()call in the API hook automatically convertstaxonomy_typefrom the response totaxonomyType— no hook changes needed.- Badge priority logic belongs in
TaxonomyTypeBadge. The component receives bothsystemDefined: booleanandtaxonomyType: 'competency' | 'tags'and applies the priority order: System-level first, then Competency, then Tags. Keeping the logic inside the component makes it testable in isolation. - Visual reference for the new component: Use the same badge/pill UI component already used by
src/taxonomy/system-defined-badge/index.jsxas the pattern. "System-level" retains its existing styling; "Competency" uses a distinct color variant; "Tags" uses a neutral color variant. - Card update:
TaxonomyCard(taxonomy-card/index.jsx, lines 122–128) currently conditionally renders<SystemDefinedBadge />whenshowSystemBadgeis true. Replace this with<TaxonomyTypeBadge systemDefined={systemDefined} taxonomyType={taxonomyType} />— always rendered, no conditional, since every taxonomy now shows a badge. systemDefinedis not removed. It remains on the interface and in existing code. This ticket does not clean it up; that is a separate concern.taxonomy_typepassthrough in edx-platform: The frontend calls/api/content_tagging/v1/taxonomies/. Verify thatTaxonomyOrgSerializer(edx-platform/openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py, lines 70–99) includestaxonomy_typein its response — this is covered by [BE][edx-platform] Verify Taxonomy Type passes through TaxonomyOrgSerializer #630, but confirm it is merged and working before testing this ticket.
Example Resolution Prompt
In frontend-app-authoring, add taxonomy type badges to the Taxonomies page. In src/taxonomy/data/types.ts, add taxonomyType: 'competency' | 'tags' to the TaxonomyData interface. Create src/taxonomy/taxonomy-card/TaxonomyTypeBadge.jsx that accepts systemDefined: boolean and taxonomyType: 'competency' | 'tags' props and renders exactly one badge: "System-level" if systemDefined is true, "Competency" if taxonomyType === 'competency', or "Tags" otherwise. Use the same badge/pill UI component as src/taxonomy/system-defined-badge/index.jsx as the visual pattern, with a distinct color variant for "Competency" and a neutral variant for "Tags". In src/taxonomy/taxonomy-card/index.jsx, replace the conditional <SystemDefinedBadge /> at lines 122–128 with <TaxonomyTypeBadge systemDefined={systemDefined} taxonomyType={taxonomyType} /> — always rendered, no conditional. Do not remove systemDefined from the interface or any existing code.
Activity
jesperhodge commentedon Jul 1, 2026
The dependencies in the ticket mention:
"[it is required] that TaxonomyOrgSerializer in edx-platform passes taxonomy_type through in the /api/content_tagging/v1/taxonomies/ response."
What ticket does that get implemented in? We should link that ticket. If none, we should create a backend ticket for it.
jesperhodge commentedon Jul 1, 2026
Claude-supported feedback:
'competency' | nullis a leaky abstraction. The component renders "Tags" for null, which means the component is encoding the business rule that "null means Tags." A cleaner API contract: the GET endpoint returns "tags" for standard taxonomies and "competency" for competency taxonomies. Then the type is 'competency' | 'tags' and the badge component doesn't need to translate null → "Tags". This inconsistency (Create accepts "tags", GET returns null) is a design smell that will confuse future consumers.Since that concerns the API schema, I'll add this comment to [BE] Update Get endpoint to return Taxonomy Type. #618 as well.
illiphilli commentedon Jul 1, 2026
Updated view of Taxonomy Cards with Paragon Badges (
infofor competencies,lightfor tags) indicating their type.Figma Link
mgwozdz-unicon commentedon Jul 2, 2026
@jesperhodge Addressing both points above, updated the ticket description to match:
On the
TaxonomyOrgSerializerpassthrough ticket: that work is tracked in #630, the edx-platform companion ticket split off from #618. Linked it in the Dependency line alongside #618. Also resolved the ticket's other placeholder links while I was in there: thetaxonomyTypefield dependency now points to #618, and the cross-reference to the import dropdown now points to #615.On the
'competency' | nullleaky abstraction: agreed, and it's the same fix already applied on #618 and #615.taxonomyTypeis now typed'competency' | 'tags'throughout — theTaxonomyDatainterface, theTaxonomyTypeBadgecomponent's props, and the Example Resolution Prompt — so the component no longer needs to treatnullas an implicit "Tags."Full updated ticket description reflects both changes.
bradenmacdonald commentedon Jul 2, 2026
Coincidentally, I was working on a prototype PR related to this, to better display the taxonomy attributes that we already have defined today, and this is my WIP proposal, for what it's worth:
openedx/frontend-app-authoring#3125
I don't think it conflicts with this.
mgwozdz-unicon commentedon Jul 6, 2026
@bradenmacdonald
I don't think it conflicts with this either. I really like the feature to provide more info up front about the orgs since that's currently really confusing without it. @illiphilli Do you have any thoughts on this?
22 remaining items
dvarenikqaconsultant commentedon Sep 22, 2026
Environment: Master Sandbox (
https://apps.master.openedx.io/authoring/home)Test user: dmitryvarenikqa
Test type: UI (manual verification + browser DevTools inspection). No API/Postman testing involved.
Overall result: Core behavior passes. One design/implementation question was raised and resolved during testing (see "Icon color" below); two coverage items are not yet independently verified for the Competency taxonomy type (see "Not yet verified").
Taxonomy type icon is always present
Verified that every taxonomy card on the Taxonomies page displays a type icon, with no card missing one. Checked both taxonomies created through the API (
POST) and taxonomies created through import, and both consistently show an icon.Icon color
Initial finding: the taxonomy type icon (
Tagicon, from@openedx/paragon/icons) rendered black, while the Figma design specifiedbackground: var(--primary-900, rgba(7, 34, 60, 1))for it, a dark navy color distinct from the black used for the taxonomy title text.Investigated in DevTools: the icon has no color set directly. Both the icon and the adjacent title text inherit
color: var(--pgn-color-black)from a shared ancestor, the ParagonCard.Headercomponent's own.pgn__card-header-title-mdclass (not custom code added for this ticket). This is a legitimate design-token binding, not an accidental default.Raised this with the designer, including the fact that
--pgn-color-black(#000000) and--pgn-color-primary-900(#07223C) are two distinct tokens. The designer decided to standardize on--pgn-color-blackfor both the icon and the text, and will update the Figma design to match. Since the design will be updated to reflect the already-implemented color, and the color is already tied to a real design token (not hardcoded), no code change is needed. No bug filed.Accessibility (screen reader label)
The ticket discussion settled on an icon-only visual with a visually hidden label for screen readers (Paragon's
IconcomponentscreenReaderTextprop), rather than a visible text label or a hover tooltip.Verified in the browser's accessibility tree for a Tags-type taxonomy card: the icon's wrapping
<span>contains asr-onlyspan with the text "Tags taxonomy", which is correctly exposed as part of the accessible name of the taxonomy card link. Confirmed both through DOM inspection (thesr-onlyspan is present) and through the Chrome DevTools accessibility tree (the static text "Tags taxonomy" appears nested inside the card's link node).