Repository navigation
[Tagging] Display the # of times each tag has been used #253
Description
Overview
What problem are we trying to solve with this feature?
Platform Administrators want to know how many times each tag is used in the LMS. This can help them identify missing content associations or understand which standards are covered most in their instance.
This feature will display the number of times each tag has been associated with content objects across the entire Open edX instance.
The usage count represents the total number of associations for a specific tag (based on existing tagging data), including:
- Courses
- Content within courses
- Content library items
This value corresponds technically to the number of rows in the oel_tagging_objecttag table where tag_id = {this_tag_id} .
The count is informational only and will not currently support selection or clicking, nor introduce reporting or analytics functionality.
In Scope
Functional Behavior
- Display a usage count for each tag (root and sub-tags).
- Count includes:
- All content association types (courses, course content, libraries).
- Both published and unpublished content.
- Count reflects direct associations only.
- No aggregation from child tags.
- If a tag has no associations, display a visible 0.
- If a tag is renamed, the usage count remains associated with the tag.
- Count is displayed only on the Taxonomy Detail page.
- Count is visible only to users who can access the Taxonomy Detail page (currently Admins).
- Backend calculates usage count from existing association data.
- Backend exposes usage count via API.
- Count does not need to update in real time.
- Count should reflect the total as of page load or instance cache TTL.
- Caching is permitted.
UI / UX Requirements
- The usage count must be clearly distinguishable from the existing child-tag count.
- Meaning must not be conveyed by color alone.
- Display must align with the Paragon design system and DataTable components.
- If Paragon components are insufficient, enhancements may be proposed.
- Zero must be explicitly displayed, not blank or hidden.
- Must meet accessibility standards:
- Proper contrast
- Pass Axe accessibility tests
Non-Functional Requirements
- Must not noticeably degrade page load performance.
- Must work correctly with paginated Paragon DataTable implementation.
- Must scale across instances with large volumes of tags and associations.
- Must not require schema changes (existing tagging data is sufficient).
- Must not expose data beyond current role authorization
Design Reference
Figma: Content Tagging MVP
https://www.figma.com/design/DmUC2e7BAoQsGDq4KgApPa/Content-Tagging-MVP
Figma: Content Tagging updated by Unicon
https://www.figma.com/design/yE6wmSFnokNM4FG1naasly/Content-Tagging-MVP?t=pUExlThj2kpH6qgM-0
Activity
[-]Display the # of times each tag has been used[/-][+][Tagging] Display the # of times each tag has been used[/+]thelmick-unicon commentedon Feb 23, 2026
Acceptance Critera
Feature: Display tag usage count on the Taxonomy Detail page
As an Admin user
The user wants to see the number of times each tag has been associated with content across the instance
So that they can identify missing content associations and understand content coverage
Usage count includes all supported content types
Given that a tag is associated with one or more content objects
And those objects include courses, course content, or content library items
When the user loads the Taxonomy Detail page
Then the displayed usage count equals the total number of those associations
And each associated object counts as one usage
Usage count includes published and unpublished content
Given that a tag is associated with published content
And the same tag is associated with unpublished content
When the user loads the Taxonomy Detail page
Then both published and unpublished associations are included in the usage count
Parent tag usage includes child tag usage
Given a taxonomy where "Natural Science" is the parent of "Chemistry" and "Physics"
And "Object A" is tagged with "Chemistry"
And "Object B" is tagged with "Physics"
And "Object B" is also tagged with "Chemistry"
When the taxonomy shows the usage count for the parent tag "Natural Science"
Then the usage count for "Natural Science" should be 2 (Object A and Object B)
And each object is only counted once, regardless of how many child tags are applied to it.
Display nothing when a tag has no associations
Given that a tag has no associated content objects
When the user loads the Taxonomy Detail page
Then nothing is displayed for that tag
Usage count remains after tag rename
Given that a tag has one or more existing associations
When the tag is renamed
And the user loads the Taxonomy Detail page
Then the usage count remains associated with that tag
And the count value does not change due to the rename
Usage count reflects the current total on page load
Given that tag associations have changed
When the user loads the Taxonomy Detail page
Then the usage count reflects the current total
Or reflects the total as of the instance cache TTL
Usage count does not degrade page performance
Given the Taxonomy Detail page contains usage counts
When the page is loaded
Then page load performance is not noticeably degraded
Usage count scales for large instances
Given an instance contains a large number of tags and associations
When the user loads the Taxonomy Detail page
Then usage counts are calculated and displayed within acceptable amount of time
Usage count meaning is not conveyed by color alone
Given visual indicators are used to differentiate counts
When the page is rendered
Then meaning is not conveyed by color alone
Usage count meets accessibility standards
Given the feature is implemented
When the page is evaluated using accessibility testing tools
Then contrast standards are met
And badge or indicator semantics are screen-reader compatible
And the page passes Axe accessibility tests
Screenshot of UI
thelmick-unicon commentedon Feb 24, 2026
illiphilli commentedon Feb 27, 2026
Better showcasing of nested levels and column header label
bradenmacdonald commentedon Mar 27, 2026
@thelmick-unicon The original AC in the issue description says
And then the AC in your comment below says:
which is the opposite.
And then the mockup from @illiphilli again reflects direct associations only.
Could you please clarify this?
Tbain/253 add tags count (#2957)
thelmick-unicon commentedon Apr 3, 2026
@bradenmacdonald We've updated the AC and included updated screenshots in the original AC comment. Copy them here for your visibility.
Parent tag usage includes child tag usage
Given a taxonomy where "Natural Science" is the parent of "Chemistry" and "Physics"
And "Object A" is tagged with "Chemistry"
And "Object B" is tagged with "Physics"
And "Object B" is also tagged with "Chemistry"
When the taxonomy shows the usage count for the parent tag "Natural Science"
Then the usage count for "Natural Science" should be 2 (Object A and Object B)
And each object is only counted once, regardless of how many child tags are applied to it.
feat: tagging APIs can properly report implicit tag usage counts (#506)
jmakowski1123 commentedon Apr 15, 2026
For test: Display zero when a tag has no associations - I do not see the zero, I see blank space.
For test: Usage count does not degrade page performance - Is there a count threshold that you are testing against? For example, I have 10 tags associated and I am not running into performance issues. Similar question about how to test: Usage count scales for large instances
For this test: Usage counts display correctly with pagination - Is this not valid given the decisions we made around pagination?
jesperhodge commentedon Apr 16, 2026
Hi @jmakowski1123 , I'll let Tyler address your comments, since it's his issue.
But I wanted to share our findings about performance.
Performance: this is a bit hard to test, since it's really a technical issue. I don't expect you to find a way to apply thousands of tags to courses. We have tested with the "Lightcast" taxonomy, which has a lot of tags in it, and also applied around 10 tags or so to some courses. The observation was that an initial attempt at this had bad performance, which just means that the backend request from the network tab took about 2 seconds (to load the tags with the counts). That's a problem because if you apply thousands of tags, that should take much longer. Braden, Tyler, and me, all tested performance locally and found that with the new / current implementation, the request takes about 100-200 milliseconds, which is great. And furthermore I locally applied around 1,000 tags to course modules, and it did not increase the time the request takes.
Since this is pretty hard to test as a non-technical user, I went to https://apps.oex.unicon.net/authoring/taxonomy/5/ (lightcast taxonomy) and checked the performance using the Chrome dev tools, and made a screenshot. You can see here that the loading time was 294 milliseconds, which is very very good.
jesperhodge commentedon Apr 16, 2026
Hi @thelmick-unicon , can I get your input here?
The design shows blank space, whereas the AC explicitly states that there should not be blank space. Could you clarify what the expected behavior here should be?
I think since we have not done pagination, this should not be an AC, right? At any rate we can't really implement this without implementing the whole pagination feature.
thelmick-unicon commentedon Apr 16, 2026
@jesperhodge
I believe we settled on no number when it's zero. I'll update the AC.
Correct, since there is no pagination, this AC should be removed.
tbain commentedon Apr 16, 2026
Hey @jmakowski1123 !
For performance question:
Thanks for jumping in @jesperhodge :) I can't really add much more about the performance beyond what Jesper said. I don't think there's a good way for an end user to test the performance aspects other than what Jesper outlined - digging into the developer tools and looking at the query times and making sure they are not egregiously longer than the page otherwise was before the implementation. As Jesper said this mainly cropped up due to an original implementation adding more than a second to the query and growing exponentially longer as taxonomies got bigger, vs. the new, more performant, implementation adds about 200ms under the same circumstances and will increase query time linearly.
All that is to say for your end user testing it depends on how in-depth you want to go with it. For my local I applied a handful of tags to a handful of objects, and I'm not sure what sort of setup Braden might have had that showed such a large query time. Jesper tested with a relatively large set as he posted above. I think to deeply exercise this you would need to apply thousands of tags across many, many courses, modules, sections and library items, but that feels like it gets into performance testing. We didn't have a particular threshold of tags, other than perhaps what Braden might have setup locally when he was testing since his results provided some consistency on the same machine with the same taxonomy, etc.
For the zero display question
Yeah that is consistent with what was shown in the Figmas and when I asked about it internally the team preferred it blank as an "at a glance" feature to be able to quickly discern what had counts and to stay consistent with the Figmas. But I think we missed updating the AC's and otherwise ensuring we were aligned. What would your expectation be? We can update the AC's or it would be easy to make it display a '0' as well.
jmakowski1123 commentedon Apr 16, 2026
I think it's better as a blank space instead of a zero. I column of blue zeros would get cluttered.