[FE] Add taxonomy type badge to Taxonomies page

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 taxonomyType is "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

Figma Link

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

taxonomyType is not yet in the frontend data layer. Add taxonomyType: 'competency' | 'tags' to the TaxonomyData interface in types.ts (lines 2–18). The camelCaseObject() call in the API hook automatically converts taxonomy_type from the response to taxonomyType — no hook changes needed.
Badge priority logic belongs in TaxonomyTypeBadge. The component receives both systemDefined: boolean and taxonomyType: '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.jsx as 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 /> when showSystemBadge is true. Replace this with <TaxonomyTypeBadge systemDefined={systemDefined} taxonomyType={taxonomyType} /> — always rendered, no conditional, since every taxonomy now shows a badge.
systemDefined is not removed. It remains on the interface and in existing code. This ticket does not clean it up; that is a separate concern.
taxonomy_type passthrough in edx-platform: The frontend calls /api/content_tagging/v1/taxonomies/. Verify that TaxonomyOrgSerializer (edx-platform/openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py, lines 70–99) includes taxonomy_type in 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.

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.

Claude-supported feedback:

Type 'competency' | null is 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.

Updated view of Taxonomy Cards with Paragon Badges (info for competencies, light for tags) indicating their type.

Figma Link

@jesperhodge

@jesperhodge Addressing both points above, updated the ticket description to match:

On the TaxonomyOrgSerializer passthrough 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: the taxonomyType field dependency now points to #618, and the cross-reference to the import dropdown now points to #615.

On the 'competency' | null leaky abstraction: agreed, and it's the same fix already applied on #618 and #615. taxonomyType is now typed 'competency' | 'tags' throughout — the TaxonomyData interface, the TaxonomyTypeBadge component's props, and the Example Resolution Prompt — so the component no longer needs to treat null as an implicit "Tags."

Full updated ticket description reflects both changes.

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.

@bradenmacdonald

@bradenmacdonald

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.

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?

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 (Tag icon, from @openedx/paragon/icons) rendered black, while the Figma design specified background: 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 Paragon Card.Header component's own .pgn__card-header-title-md class (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-black for 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 Icon component screenReaderText prop), 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 a sr-only span 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 (the sr-only span is present) and through the Chrome DevTools accessibility tree (the static text "Tags taxonomy" appears nested inside the card's link node).

Navigation Menu

Repository navigation

[FE] Add taxonomy type badge to Taxonomies page #616

Use Case

Description

Acceptance Criteria

UX Designs

Technical Notes

Files to Create

Modified Files

Implementation Notes

Example Resolution Prompt

22 remaining items

Taxonomy type icon is always present

Icon color

Accessibility (screen reader label)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FE] Add taxonomy type badge to Taxonomies page #616

Description

Use Case

Description

Acceptance Criteria

UX Designs

Technical Notes

Files to Create

Modified Files

Implementation Notes

Example Resolution Prompt

Activity

jesperhodge commented on Jul 1, 2026

jesperhodge commented on Jul 1, 2026

illiphilli commented on Jul 1, 2026

mgwozdz-unicon commented on Jul 2, 2026

bradenmacdonald commented on Jul 2, 2026

mgwozdz-unicon commented on Jul 6, 2026

22 remaining items

dvarenikqaconsultant commented on Sep 22, 2026

Taxonomy type icon is always present

Icon color

Accessibility (screen reader label)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions