Add non-contributor users with readonly access to embargoed dandiset

[magland]

Proposed change

There are times when you may want to share an embargoed dandiset with DANDI users who are not actually contributors, for example giving them readonly access so they can run some processing on it or generate visualizations. Right now I think the only way to do this is to add them as contributors. But this doesn't seem appropriate if they have not actually contributed to the creation of the dandiset. I am thinking specifically about my situation, where I'd like access to some embargoed dandisets for the purpose of helping with processing or generating visualizations.

Perhaps the simplest way to make this change is to optionally flag a "contributor" as non-contributing. That sounds silly, so there's probably a better name for it: "viewer" or "read-only-member". Then on the dandiset page, they would be listed as "viewers", separate from "contributors" (or perhaps not listed at all). In order to not have to make structural changes to the data model, I would suggest that they could still be included internally in the list of "contributors".

Who would use this feature?

This feature would be very helpful to users who would like to request read-only access to embargoed datasets without needing to be added as contributors.

(Optional): Suggest a solution

As mentioned above, add a flag such as "read-only-member" or "viewer" to a contributor. Then list them differently (or not at all) on the main dandiset page.

[satra]

@magland - this has been discussed as a feature several times, and falls into a broader category of access control whether role or resource based. this continues to come up for various use cases and we do need a way of enacting subsets of this request.

i'll summarize some related requests:

• restricted access with data use authorization workflow
• private test datasets for ML challenges
• anonymous access to embargoed data during review of publications
• write access to parts of dandisets so that data contributors don't overwrite/delete other parts
• view access to parts of dandisets
• teams with specific roles

we will discuss this internally and see if we can come up with a roadmap for this cluster of features and an estimated timeline. it also very minimally intersects with an internal refactor of embargo that we are carrying out right now.