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

Overview

In the scope of the Easy Sharing of Community Channels, there will be a need for specific channel versions to be imported into Kolibri:

1. Channel versions related to a specific Submission so that Community Library Submissions can be QA-ed by importing them into Kolibri.
2. Channel draft versions, since they are represented as a new upcoming version.

Currently, the way Kolibri has to get the information of non-public channels is by using a token, which is represented by the SecretToken model, which has a many-to-many relation with the Channel model so that it can then look up by the get_public_channel_lookup api with the token sent as the identifier.

The problem is that this SecretToken is associated only with a given Channel, so no specific channel version databases can be retrieved via this endpoint.

Technical details

To enable using secret tokens to import specific channel versions, a new ChannelVersion model should be created, and a One-To-One relationship with the SecretToken model should be established, so that the public lookup endpoint can look up specific channel versions. This new model will replace the purpose of the current published_data channel field, but we won't remove it yet, and will instead use both in parallel for now.

Model

The ChannelVersion model will have the following fields:

• id: A UUID field.
• channel: A ForeignKey to the Channel model. Non nullable.
• version: A PositiveIntegerField to store the channel version number. Nullable. Null versions represent draft versions.
• secret_token: A ForeignKey to the SecretToken model. Nullable.
• version_notes: A TextField to store the version notes. Nullable.
• size: A PositiveIntegerField to store the channel published_size field. Nullable.
• date_published: A DateTimeField to store the channel's last_published field. Nullable
• resource_count: A PositiveIntegerField to store the channel resource count. Nullable
• kind_count: An ArrayField to store the kind_counts json objects. These look like this: { "count": 2, "kind": "document" }. A validator function should be created to validate the schema of the array items and passed using the validators arrayfield prop. Nullable.
• included_licenses: An ArrayField to store the included licenses. Array items will be IntegerFields, and a choices field could be used to specify the valid choices using the licenses.LICENSELIST list. Nullable.
• included_categories: An ArrayField to store the included categories. Array Items will be CharFields, and a choices field could be used to specify the valid choices using the le-utils subjects list. Nullable.
• included_languages: An ArrayField to store the included languages. Use a validator function to validate that array items are valid languages. Nullable.
• non_distributable_licenses_included: An ArrayField to store the non-distributable licenses included in the channel snapshot. Should be validated in the same way as included_licenses is. Nullable.
• special_permissions_included: A Many-To-Many field to store the references to the special permissions license descriptions included in the channel snapshot. Nullable.

Additionally, update the Channel model to include a new version_info field to reference the ChannelVersion model. Use channel as the related name in ChannelVersion. This will create two parallel references between Channel and ChannelVersion: first, the ChannelVersion will have a One-To-Many relationship with Channel, which will represent the channel version history. And Channel will have a One-To-One relation with ChannelVersion, this relationship will represent the channel's most recent version data, and will help to make the most common query easier to read. This comes at a cost at writing time to ensure data consistency between these models:

• In the Channel on_update method, we need to make sure that if a version field is set for the channel, there is a related version_info object, whose version is the same as the channel version field.
• In the ChannelVersion model, on its save method, validate that the version field is set to a value less than or equal to the channel version field.
• The ChannelVersion model should have a composed unique constraint ("channel", "version").

Updated usages

• Create a new_token method in the ChannelVersion model similar to this

• Update the increment_channel_version function to:

  • Receive a new is_draft_version argument.
  • Only when is_draft_version is false, the channel version integer is updated.
  • In any case, create a new ChannelVersion instance, with the version field set to null if the channel is draft, or set to the same channel version number if not.
  • Only when is_draft_version is false, set the new ChannelVersion instance to the channel.version_info object.
  • Only when is_draft_version is true, create a new token for the draft ChannelVersion instance.

• In the publish_channel function, move the call to the increment_channel_version function to be called always, and not only for non-draft versions.

• Update the fill_published_fields function to update the channel.version_info using the published_data info of the given channel, and to update the channel's version_info field.

• Update the get_published_data endpoint (this endpoint was introduced in the scope of the ESoCC project) to be get_version_detail to return the version_detail field of a given channel, and update all its usages in the frontend.

• Update the CommunityLibrarySubmission save method, to query the related ChannelVersion, and call its new_token method when a new CommunityLibrarySubmission is being created.

  • As per this, we will only create secret tokens if needed, and not for every single channel version.
  • In a follow-up Issue, we will update the CommunityLibrarySubmission model to reference the ChannelVersion model instead of using the channel and version fields.

Acceptance criteria

• A new ChannelVersion model is created, and new instances are created when a channel is published.
• New secret tokens are created for draft version channels and channels with related Community Library Submissions.
• The get_published_data endpoint is migrated to return just the new version_info channel field.
• Unit tests are added to cover the new workflows.