Add ContentNode.options option to control content downloadable setting

[kollivier]

Observed behavior

Currently, download settings can only be controlled at the device / facility level. Some content either cannot, or should not be downloadable, while other content is licensed such that downloading is explicitly allowed.

We should add a flag that allows the content to specify whether or not it should be downloadable, and allow this flag to supercede the device / facility setting when appropriate.

Expected behavior

…

User-facing consequences

Users can download content they should not be able to, or they cannot download content that explicitly allows for it.

Errors and logs

…

Steps to reproduce

…

Context

…

[jonboiser]

Does this options field exist on ContentNodes in Kolibri Studio?

[kollivier]

It does in the backend, but we haven't yet decided how best to expose it in the frontend. It would primarily benefit ricecooker channels for now.

[jonboiser]

Ah, okay. So to me this should probably be blocked until we know how you want to present this info on the Studio front-end so we're consistent on Kolibri.

But I think in the meantime, if there exist published channels with this field, we can get started on integrating it with the Kolibri backend (e.g. updating models and serializers, etc.)

Unless, the scope of this issue is simply to expose this options field on the API layer, and then defer the UI work to a different issue.

[kollivier]

How I was originally thinking of it was to scope this such that Kolibri recognizes and responds to the option when set. We would be mostly setting this via ricecooker for now. Studio frontend support would be phase 2. (e.g. we already have a coupel HTML5 app options that work like this in Kolibri.)

[jonboiser]

Is there a published channel that we can see this option on? I think the "recognizes and respond to" part might need some design, esp. since I'm not sure I think this

and allow this flag to supercede the device / facility setting when appropriate.

needs some clarification and may involve implementing yet more Facility/Device settings to set the desired policy. Like, one use case for disabling downloads is that people don't want learners to download content to a tablet and take up space, so IDK if a curator should be able to override that decision.

But exposing these options on the API layer is something we can do right now, and would make actually implementing UI changes a little easier.

[rtibbles]

Note that the options field is already being loaded to the frontend: https://github.com/learningequality/kolibri/blob/release-v0.14.x/kolibri/core/content/api.py#L306 (it is used in HTML5 apps to determine default iframe sizing).

I think the safest thing is for the flag to only prevent downloads for now, as that is the primary use case to prevent downloads of content from the channel level. So this would just be only allow download if device download setting and not no download content flag.

[kollivier]

Yeah, agreed, on further thought prioritizing the facility default makes more sense!