Remove Collections Model?

[connorhaugh]

Collections are the abstraction for a set of learning contexts or bundles.

The idea behind collections was that they can be used to apply permissions and other metadata to many learning contexts at once, with more flexibility than org-based permissions. If Bob works at Harvard and manages 30 courses with a small team of TAs and two other profs, he can use a Collection to group them together and manage the permissions, rather than having to give everyone at Harvard access or manage the permissions for each course/library individually.

• @bradenmacdonald

The issue we are encountering is twofold:

1. Features have not been built to enable the situations described above, therefore, the feature has very little purpose.
2. Collections are a pain point in the present. It is very hard to determine which collection to use when writing code that creates content libraries. The MFE knows the collection uuid, but that isn’t configured anywhere on the backend. I can just grab the first collection from the django model, but that doesn’t seem like it would be correct forever? Another important impact of this is in the context of pre-provisoned environments like sandboxes. Putting the collection uuid in a MFE config file at build time wouldn’t work, as the collection would not exist yet.

We are unsure of the long term plans for 1. but are certain of 2. Therefore, we think it would be prudent to simply remove the concept of collections from blockstore entirely. In the meantime, it might be worthwhile to specify a default value for the collection uuid and then make that the value.

[bradenmacdonald]

I support removing Collection. It can be removed in a backwards-compatible way simply by making the various API endpoints ignore the collection_id parameter. The model itself is tiny and has no real useful data:

https://github.com/openedx/blockstore/blob/1d19682cc845a0dab00f0ec01581879e400c99a0/blockstore/apps/bundles/models.py#L73-L89