Automate owner group, etc. management

[jl-wynen]

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