Use Case
As a Platform Administrator, I need the taxonomy Get endpoint to return the Taxonomy Type so that platform interfaces can identify which taxonomies are Competency Taxonomies and which are standard tag taxonomies.
Description
This issue updates the taxonomy retrieval API to include a taxonomy_type field in the response for both the single-taxonomy (GET /api/tagging/v1/taxonomies/{id}/) and list (GET /api/tagging/v1/taxonomies/) endpoints. The field returns "competency" for Competency Taxonomies and null for all other taxonomies. The returned "competency" value must match what the Create endpoint accepts.
This ticket covers the read path only. It does not add write behavior, change authorization rules, or alter any other field in the response. System-level taxonomy behavior (system_defined) is unchanged and out of scope.
Also in scope: Verify that TaxonomyOrgSerializer in edx-platform (openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py) does not exclude taxonomy_type from its response — the frontend Taxonomies page calls the edx-platform endpoint, not the openedx-tagging endpoint directly. Patch if needed.
Dependency: Requires the CompetencyTaxonomy model ([link to data model ticket]) and the updated Create endpoint ([link to Create ticket]) to be merged first.
Acceptance Criteria
These scenarios are verifiable via Postman against a local or dev environment.
Scenario 1: Retrieving a Competency Taxonomy
Given a taxonomy exists that was created as a Competency Taxonomy
When I send GET /api/content_tagging/v1/taxonomies/{id}/
Then the response includes a taxonomy_type field
And the taxonomy_type value is "competency"
Scenario 2: Retrieving a non-Competency Taxonomy
Given a taxonomy exists that is not a Competency Taxonomy
When I send GET /api/content_tagging/v1/taxonomies/{id}/
Then the response includes a taxonomy_type field
And the taxonomy_type value is null
Scenario 3: Retrieving the taxonomy list
Given both Competency Taxonomies and non-Competency Taxonomies exist on the platform
When I send GET /api/content_tagging/v1/taxonomies/
Then each taxonomy in the response includes a taxonomy_type field
And Competency Taxonomies return "competency"
And all other taxonomies return null
Technical Notes
Files to Create
None expected.
Modified Files
openedx-core
| File |
Nature of modification |
src/openedx_tagging/rest_api/v1/serializers.py |
Add taxonomy_type as a read-only SerializerMethodField returning "competency" or null |
src/openedx_tagging/rest_api/v1/views.py |
Add select_related('competencytaxonomy') to get_queryset() to prevent N+1 on list |
edx-platform
| File |
Nature of modification |
openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py |
Verify TaxonomyOrgSerializer (lines 70–99) does not exclude taxonomy_type from its Meta.fields; add it if missing |
Implementation Notes
SerializerMethodField logic:
def get_taxonomy_type(self, obj):
if hasattr(obj, 'competencytaxonomy'):
return "competency"
return None
No system_defined check — this field is deliberately oblivious to system taxonomies. System taxonomies return null here, the same as standard tag taxonomies. The system_defined field on the response already handles system taxonomy identification and is unchanged by this ticket.
-
N+1 risk on list: Add .select_related('competencytaxonomy') to get_queryset() on TaxonomyView. Django joins the table once; hasattr on a pre-fetched miss returns False without an extra query.
-
Consistency with Create endpoint: The "competency" value returned here must exactly match the accepted input on the Create endpoint. Define it once as a named constant and reuse it in both the serializer method and the write-side ChoiceField validator.
-
Read-only field: Mark taxonomy_type as read_only=True to prevent any risk of it being written via PATCH.
-
edx-platform passthrough: TaxonomyOrgSerializer extends TaxonomySerializer. If its Meta.fields is an explicit list, taxonomy_type must be added to it. If it uses fields = '__all__' or inherits without override, no change is needed — just verify.
Example Resolution Prompt
In openedx-core/src/openedx_tagging/rest_api/v1/serializers.py, add taxonomy_type as a read-only SerializerMethodField on TaxonomySerializer. The method returns "competency" if hasattr(obj, 'competencytaxonomy'), and None otherwise. Do not check system_defined — this field is intentionally oblivious to system taxonomy status. In views.py, add .select_related('competencytaxonomy') to TaxonomyView.get_queryset(). Define "competency" as a named constant shared with the Create endpoint's ChoiceField. In edx-platform/openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py, check whether TaxonomyOrgSerializer (lines 70–99) has an explicit Meta.fields list; if so, add taxonomy_type to it.
Use Case
As a Platform Administrator, I need the taxonomy Get endpoint to return the Taxonomy Type so that platform interfaces can identify which taxonomies are Competency Taxonomies and which are standard tag taxonomies.
Description
This issue updates the taxonomy retrieval API to include a
taxonomy_typefield in the response for both the single-taxonomy (GET /api/tagging/v1/taxonomies/{id}/) and list (GET /api/tagging/v1/taxonomies/) endpoints. The field returns"competency"for Competency Taxonomies andnullfor all other taxonomies. The returned"competency"value must match what the Create endpoint accepts.This ticket covers the read path only. It does not add write behavior, change authorization rules, or alter any other field in the response. System-level taxonomy behavior (
system_defined) is unchanged and out of scope.Also in scope: Verify that
TaxonomyOrgSerializerin edx-platform (openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py) does not excludetaxonomy_typefrom its response — the frontend Taxonomies page calls the edx-platform endpoint, not the openedx-tagging endpoint directly. Patch if needed.Dependency: Requires the
CompetencyTaxonomymodel ([link to data model ticket]) and the updated Create endpoint ([link to Create ticket]) to be merged first.Acceptance Criteria
These scenarios are verifiable via Postman against a local or dev environment.
Scenario 1: Retrieving a Competency Taxonomy
Scenario 2: Retrieving a non-Competency Taxonomy
Scenario 3: Retrieving the taxonomy list
Technical Notes
Files to Create
None expected.
Modified Files
openedx-core
src/openedx_tagging/rest_api/v1/serializers.pytaxonomy_typeas a read-onlySerializerMethodFieldreturning"competency"ornullsrc/openedx_tagging/rest_api/v1/views.pyselect_related('competencytaxonomy')toget_queryset()to prevent N+1 on listedx-platform
openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.pyTaxonomyOrgSerializer(lines 70–99) does not excludetaxonomy_typefrom itsMeta.fields; add it if missingImplementation Notes
SerializerMethodFieldlogic:No
system_definedcheck — this field is deliberately oblivious to system taxonomies. System taxonomies returnnullhere, the same as standard tag taxonomies. Thesystem_definedfield on the response already handles system taxonomy identification and is unchanged by this ticket.N+1 risk on list: Add
.select_related('competencytaxonomy')toget_queryset()onTaxonomyView. Django joins the table once;hasattron a pre-fetched miss returnsFalsewithout an extra query.Consistency with Create endpoint: The
"competency"value returned here must exactly match the accepted input on the Create endpoint. Define it once as a named constant and reuse it in both the serializer method and the write-sideChoiceFieldvalidator.Read-only field: Mark
taxonomy_typeasread_only=Trueto prevent any risk of it being written via PATCH.edx-platform passthrough:
TaxonomyOrgSerializerextendsTaxonomySerializer. If itsMeta.fieldsis an explicit list,taxonomy_typemust be added to it. If it usesfields = '__all__'or inherits without override, no change is needed — just verify.Example Resolution Prompt
In
openedx-core/src/openedx_tagging/rest_api/v1/serializers.py, addtaxonomy_typeas a read-onlySerializerMethodFieldonTaxonomySerializer. The method returns"competency"ifhasattr(obj, 'competencytaxonomy'), andNoneotherwise. Do not checksystem_defined— this field is intentionally oblivious to system taxonomy status. Inviews.py, add.select_related('competencytaxonomy')toTaxonomyView.get_queryset(). Define"competency"as a named constant shared with the Create endpoint'sChoiceField. Inedx-platform/openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py, check whetherTaxonomyOrgSerializer(lines 70–99) has an explicitMeta.fieldslist; if so, addtaxonomy_typeto it.