Add library enum field to v1 and v2 public channel API responses

[rtibbles]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

The v1 and v2 public channel API endpoints need to return a library enum field to allow Kolibri to identify whether a channel is part of the Kolibri Library, Community Library, or neither.

Complexity: Medium
Target branch: unstable

Context

The v1 public channel endpoint at /api/public/v1/channels/lookup/{token} already distinguishes between channel-level tokens and channel version tokens (#5772). Community library tokens are channel version tokens — they are created when a CommunityLibrarySubmission is made, and attached to the corresponding ChannelVersion via its secret_token field.

Studio can determine whether a token is a community library token by checking if the ChannelVersion associated with the resolved token has a matching CommunityLibrarySubmission with an approved or live status. The Channel.is_community_channel() method already exists for this check at the channel level.

The relevant code is in:

• contentcuration/kolibri_public/views_v1.py — v1 endpoint handler
• contentcuration/contentcuration/models.py — ChannelVersion, CommunityLibrarySubmission, Channel.is_community_channel()

The Change

When the v1 endpoint resolves a token, include a library enum field in the response using values from le-utils (learningequality/le-utils#214): "KOLIBRI" for public channels, "COMMUNITY" for community library version tokens (where the associated ChannelVersion has a CommunityLibrarySubmission with approved or live status), and null otherwise.

Add a library field to the v2 channel metadata response: "KOLIBRI" for public channels, "COMMUNITY" for non-public channels.

Update the le-utils dependency to include the new library constants.

We should also update the v1 endpoint to require a special query parameter in order to resolve tokens against ChannelVersion objects - "channel_versions=true". Otherwise, the ChannelVersion lookup path should be skipped. This will prevent older Kolibris from accidentally retrieving data they will not parse correctly.

How to Get There

The v1 lookup logic in contentcuration/kolibri_public/views_v1.py already has the resolved token type available:

• For channel version tokens, the ChannelVersion object is available — check if it has a CommunityLibrarySubmission with approved or live status → "COMMUNITY"
• For regular channel tokens, check channel.public → "KOLIBRI"
• Otherwise → null

Acceptance Criteria

• V1 channel lookup response includes a library field
• V2 channel metadata response includes a library field
• Channel version tokens with an approved/live CommunityLibrarySubmission return library: "COMMUNITY"
• Regular channel tokens for public channels return library: "KOLIBRI"
• All other tokens return library: null
• V2 public channels return library: "KOLIBRI", non-public return library: "COMMUNITY"
• le-utils dependency updated to include library constants
• v1 chanenl version token resolution is gated behind the channel_versions=true query parameter

Testing

• Tests cover all three library values (KOLIBRI, COMMUNITY, null) across token types on v1
• Tests cover library field on v2 for public and non-public channels

References

• Add support for channel version tokens on v1 public channel endpoint #5772 — Added channel version token support to v1 endpoint

AI usage

Used Claude Code to draft this issue interactively. I provided the requirements and Claude explored the Studio codebase to understand the token resolution and community library submission models. All content reflects my decisions and was reviewed section by section.

[rtibblesbot]

Watching for resolution on behalf of learningequality/kolibri#14588.

[rtibblesbot]

Plan: Add a library enum field ("KOLIBRI", "COMMUNITY", or null) to the v1 and v2 public channel API endpoints, and gate v1 ChannelVersion token resolution behind a channel_versions=true query parameter.

• Bump le-utils to 0.2.17
• Write the failing gate test
• Implement the gate in _get_channel_list_v1
• Update the three existing channel-version tests
• Write failing tests for V1 library field
• Implement library in _serialize_channel_version()
• Add library field to PublicChannelSerializer
• Write failing tests for V2 library field
• Implement library in V2 consolidate()

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
• Ran the project's full test suite and linter before committing
• For UI changes: captured live screenshots to verify rendering
• For backend changes: verified with example API/CLI output