Skip to content

[BE] Update taxonomy Get endpoint to return Taxonomy Type #544

Description

@mgwozdz-unicon

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions