Living library

[innovativeangela]

Currently both static (PDF) and editable versions of toolkits are stored in the repo living-source-files. These represent versions of the toolkits at a point in time, but some are being updated by publishers. Also, some are being remixed and published by others as variants. OPSI would like to serve as an archival repository of toolkits, both enabling users to download the most recent editable files as well as upload remixed versions.

Three things need to be displayed on each toolkit detail page: A link to the static files (if it/they exist(s) in living-source-files) A link to the editable files (if it/they exist(s) in living-source-files) A link to other variants of a given toolkit (points to a filtered view of toolkits) A button for users to submit a variant of the toolkit

This would require the ability for administrators to link toolkit variants manually.

This feature is quite conceptual at this point and many possible options exist for its development. More discussion is needed to refine this feature.

[marcochiesi]

I need a clarification on this: are Toolkit variants just a bunch of additional files/links or are they additional full Toolkits in the database? I supposed the 2nd one. In that case, I think the implementation could be made with the following set of fields (using Advanced Custom Fields):

• One or more link (using a repeater field) to static files
• One or more link (using a repeater field) to editable files
• A relationship field that will allow connecting each toolkit with any other toolkit (with multiple connections). This could be made in a bidirectional way so that when you set up a connection, it's stored also in the other way without the need of editing the connected Toolkit(s).

With regards to "the button to submit a variant", I suppose it will bring to a Toolkit submission form (the same one mentioned in #12). Do you think would it be necessary an optional field like "This Toolkit is avariation of..."?

[innovativeangela]

It is the second option you mentioned (additional full toolkits). I think your suggested implementation (including the Toolkit connections and Toolkit submission form suggestions) could work well. On #12 yes I do think there should be a field like "This Toolkit is a variation of..." for users who access the Toolkit submission form directly instead of accessing via the "submit a variant" button. Could this additional field pull from the existing list of Toolkits?

[marcochiesi]

For the sake of completeness here's a recap of how the features included in this issue will be implemented:

• In the backend add a repeater field that will allow inserting multiple links to static files
• In the backend add a repeater field that will allow inserting multiple links to editable files
• In the backend add a "relationship" field that will allow admins to connect each Toolkit with their variants. This could be made in a bidirectional way so that when you set up a connection, it's stored also in the other way without the need of editing the connected Toolkit(s).
• In the frontend, in the Toolkit detail page, display all the above pieces of information (links to static files, to editable files and to variants)
• In the frontend, in the Toolkit detail page, there will be a button "Submit a variant" that will bring the user to the Toolkit submission form.
• In the submission form (see #12) there will also be the same set of the fields described above. If the user comes from the "Submit a variant" button, the relationship field for variations will be prepopulated with the relevant Toolkit.