Sharing custom field visibility options within a study

[simroux]

This is a feedback / user request coming from the GSC workshop, probably a low-priority feature request but I wanted to create an issue while still fresh in my mind :-). It seems like there is (a large) interest for users to toggle field visibility, then share these choices with others in the same study. The use case is a PI with a group of undergrads who will do the actual sampling: their "ideal" process would be (i) they create a study, and pre-select fields to be visible in the App, (ii) the students go into the field, and only see these fields to fill in so are not overwhelmed / have less chances of making mistakes.

Thinking (briefly) about this, I feel one way to do this would be to allow for these field visibility options to be stored and shared at the study level ? So my thoughts/questions for now would be:

• 1: Could we store custom field visibility options at the study level, and set them available for all users when in this study ?
• 2: Could we store multiple custom field visibility options per extension/package ? (may be complex, but I could imagine users asking for this as soon as 1 is implemented, could be fine to say "no we can't")
• 3: Could we export / import multiple custom field visibility options across studies ? (same as 2, I could imagine it being useful, but also not a major barrier, worst case scenario PIs just have to redo the initial selection for their new study, should be reasonable).

[eecavanna]

During today's squad meeting, I proposed the following as a potential solution. This is an elaboration on item 3 in the issue description above. It doesn't involve any servers or any distributing of files.

Export

The "export" could be achieved by allowing the user to get the custom field visibility options as a URL with the options embedded into it (e.g. as a query parameter), similar to how diagrams.net can generate a URL that has the diagram data, itself, embedded into it. So, the PI can generate such a URL and then provide that URL to his or her students.

Import

We can then update the app's deep link-handling code to check for that payload and—if found—update the app's field visibility options to match it. So, when a student visits that URL, their app automatically adopts those field visibility options.

[pkalita-lbl]

@pkalita-lbl consider splitting this into a few issues

[pkalita-lbl]

See also #191 for details on confusion around the current workflow

[pkalita-lbl]

Feedback from Emiley: when selecting which slots to include from a template in a study, the sample name, collection date, and lat/lon slots should be prioritized above all other slots for every template.

[pkalita-lbl]

This is what I propose we do for the v1 release:

1. Store the field visibility settings as an attribute of the Study (technically speaking the SubmissionMetadata object, as the backend calls it). This means that all users with access to a given Study will see the same set of visible fields. This also means that if a user has access to two Studies, they may see different sets of visible fields on those two Studies.
2. Add a step to the Study creation process where the user chooses which fields should be visible for that Study. This interface should visually prioritize and pre-select slots that we determine are likely to be collected in the field.
3. The user should be able to get back to the slot selection interface through the Study edit interface.
4. The slot selection interface should allow applying the slot visibility settings of a different Study (of the same template) to the current one.

[pkalita-lbl]

From 2024-11-18 squad meeting:

• Consider saving the name of the user who last updated the field visibility settings for a Study and the timestamp of the update.