Develop a plan for supporting "collections" within opencodelists

Why are we doing this?

Users have requested some way of grouping collections of codelists. We could create the concept of a "collection" - a many to many mapping to codelists. This would help group codelists together e.g. for a particular grant, project etc. However it doesn't satisfy the requirement of the original poster because they want a group of people to be able to edit/update any codelist in the collection - which would not be possible when linking to other people's codelists.

As a quick workaround, we can mis-use the organisation functionality. We can create an org for the original poster, and all codelists for the grant can be created by that new org. The downside is that this requires re-creating any codelist that you want to reuse from someone else and leads to duplication of codelists. Therefore we need a better long term solution. This solution may partly be about how codelists are versioned, e.g. by allowing someone to create a codelist based on an existing one, in order to tweak or update it. If this versioning was possible, then the simple "collection" as a many to many mapping to codelists would probably be sufficient, because you could create a collection, pull in any codelists that don't need changing, create new ones that don't exist, and updating existing codelists that you don't own.

This ticket is to track the progress towards developing the long term solution.

How will we know when it's done?

We will have a plan for creating collections in opencodelists, and tickets to implement it. Alternatively we will have decided against it and will close this with a note to that effect.

What are we doing?

• Create an organisation for the initial requester so they can achieve their goals
• Gather feedback on how the user finds using an org to group codelists
• Develop a plan for implementing collections

Defining delivery tasks guidance

Start by reviewing how the existing organisation workflow supports grouping codelists and gather feedback on that workaround. Compare collection membership, editing permissions, and codelist versioning against the stated user need. Done means documenting a long-term plan with implementation tickets, or recording a decision not to pursue collections.