You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we rely on the user to set owner_group, access_groups, and instrument_group in SciCat. For files, we use whatever UID and GID SFTP assigns. This means that metadata and files are potentially not accessible by collaborators or a user might even lock themselves out from accessing a dataset. We should prevent bad mistakes and automate setting these fields as much as possible.
Here are some ideas. But now too little to come up with a good solution at the moment.
Dataset
Problems
User can accidentally choose a group that excludes their collaborators.
User can accidentally choose a group that includes too many people.
User can accidentally choose a group they themselves are not a member of. (Don't know is SciCat actually allows this. Or if it should be allowed. Will auto-reduction jobs be owned by the correct group? Or will they be in a separate group that has access to large parts of SciCat?)
Solutions
If groups are unset, check SciCat to find a group the user belongs to.
pro: automatic
con: users can belong to be many groups, we cannot pick one of them automatically
Use the group of the proposal if the dataset is linked to a proposal
pro: gives access rights to everyone who is part of the proposal
con: are proposals public? if so, the access_groups or instrument_group may be too large
If a (owner_)group is set, check if the user is part of that group, and if not, reject the upload.
pro: would prevent users from locking themselves out
con: see comment on auto-reduction
con: should be the responsibility of SciCat
Files
Problems
If we don't set a UID and GID, they (may) be set to the uploading user which locks out all collaborators.
User can accidentally choose a group that excludes their collaborators.
User can accidentally choose a group that includes too many people.
User can accidentally choose a group they themselves are not a member of. (Does the OS allow this?)
Solutions
Use dataset.owner_group
pro: limited access but large enough for direct collaborators
con: may exclude important people
Use dataset.access_groups or dataset.instrument_group
pro: includes a bunch of people, so the uploader is not the only one with access rights
con: may include too many people
con: may exclude relevant people if they are only part of owner_group
con: how to choose an access group from the list?
If a (owner_)group is set, check if the user is part of that group, and if not, reject the upload.
pro: would prevent users from locking themselves out
con: see comment on auto-reduction
The text was updated successfully, but these errors were encountered:
Currently, we rely on the user to set
owner_group
,access_groups
, andinstrument_group
in SciCat. For files, we use whatever UID and GID SFTP assigns. This means that metadata and files are potentially not accessible by collaborators or a user might even lock themselves out from accessing a dataset. We should prevent bad mistakes and automate setting these fields as much as possible.Here are some ideas. But now too little to come up with a good solution at the moment.
Dataset
Problems
Solutions
access_groups
orinstrument_group
may be too largeFiles
Problems
Solutions
dataset.owner_group
dataset.access_groups
ordataset.instrument_group
owner_group
The text was updated successfully, but these errors were encountered: