As an admin, I'd like to be able to entirely delegate requests for access to depositors/owners

[BPeuch]

Version: 4.20

Howdy,

Here at the State Archives of Belgium, the way we handle data ingests and data access rests on two principles:

1. Users can create dataset drafts, but they may not publish their datasets by themselves. They must submit them for review, and after an admin has checked the data and metadata and found everything compliant, the admin will publish the dataset.

This of course is easily achieved by going to the admin panel and making users Contributors (and not Curators) by default:

2. Admins delegate requests for access to depositors entirely. If a user wants to reuse data files with restricted access, their requests should go directly to the depositors, without the State Archives admins having to play a middleperson's part.

That, however, is not as easily feasible considering the above: if users are only Contributors, then they don't enjoy the ManageDatasetPermissions privilege even for their own datasets. And it is (AFAIK) this privilege that determines who receives notifications of requests for access in their mailbox. 📨

So if the depositors' default role (Contributor) does not have this privilege, it is the admin who receives an e-mail notification of requests for access for each and every published dataset.

One solution is to create a custom role that has the ManageDatasetPermissions privilege and to systematically assign that role to depositors immediately after their dataset is published. In this way, they will receive e-mail notifications. 📨

However, as very aptly described here by @mdmADA and several times elsewhere in the discussion by @pdurbin (thanks again for bringing this issue to my attention), this is not without risks: once given the ManageDatasetPermissions privilege, a depositor could theoretically upgrade their status to that of e.g. Curator or even Admin for their own dataset and, from here, when they want to create a new version of their dataset, they could immediately publish it, which is contrary to our publishing policy (as described above, principle 1).

Now, as pointed out by @mdmADA, I think we can trust that most users will likely not abuse such powers, and first of all they would need to even notice that this is a possibility for them. Still, there is a risk. 💣

@scolapasta has very clearly explained here that the philosophy of IQSS is to implement features that cover the broadest cases possible, and that is obviously very sound. Constantly making adjustments and patches for particular situations and requirements can only make software increasingly complex and harder to use.

That being said, I think our use case will become more and more widespread in the future, especially since Dataverse, being such a robust, lightweight program that is both free and open source, is likely to be more and more adopted by small, aspiring data archives in the future, ones that will want to delegate transactions between depositors and reusers as much as possible. @poikilotherm has already mentioned that the situation of Jülich Forschungszentrum is similar to ours.

What we suggest: Adding a functionality that makes a user the recipient of requests for access. This could be a "privilege" (as I have called it) of certain roles.

[BPeuch]

As a note: I wrote 'depositor' but this is overly restrictive:

• There can be more than one person responsible for managing access requests, and this is currently possible simply by attributing the ManageDatasetPermissions privilege to several users (just like it's possible to have more than one contact person thanks to the repeatable Contact field in dataset metadata);
• At some point the depositor can pass away, quit the position in which they carried out the deposit (thereby, possibly, relinquishing the responsibility of managing requests for access) or simply have this responsibility taken away from them for any number of reasons or even relinquish it themselves;
• There can even be situations in which a totally different person, other than the depositor, is designated to manage access requests right from the go.

So it's so not much about the depositor, as it is about being able to designate a 'mailbox' for specific datasets, to ensure that this or these persons receive not only messages sent out via the (versions 5+) Contact Owner button but also the requests sent out via the Request Access button.

[pdurbin]

@BPeuch please check out pull request #8174 where there's a proposal to split a new permission called "ManageFilePermissions" from the existing "ManageDatasetPermissions" permissions. This is for the following issue:

• Split off GrantFileAccess permission from ManageDatasetPermissions Split off GrantFileAccess permission from ManageDatasetPermissions #8109

[BPeuch]

Wonderful! Thanks a lot for the heads-up, @pdurbin 👍

[poikilotherm]

This is still a thing for us, too. I just had a quick idea and it would be nice to have some feedback.

What if we add a limitation to the ManageDatasetPermissions or the logic behind that one may not assign a "higher" role to someone else/yourself than your own? ("Higher" meaning cannot assign roles with permission bits you do not currently have)

Maybe I have it all wrong in my head, but wouldn't that allow for a role that has the ManageDatasetPermissions but cannot get the PublishDataset bit? Like Contributor < Dataset Manager < Curator

I don't think the ability to create new roles from the UI/API would be a loophole as it requires superuser rights to do this.

[pdurbin]

@BPeuch you're welcome. In the end, the new permission got called ManageFilePermissions and shipped with 5.9 (from the pull request above). Have you had a chance to play with it? Does it meet your needs? Thanks.

[BPeuch]

Ah sorry about that @pdurbin. I thought it was only something in relation to, but not directly concerning, this issue. But I just read the description of QQMyers' PR and it's exactly what we need. So I'm closing this issue. Many thanks!

[BPeuch]

@pdurbin PS: Just tested it in our test instance (v5.11.1): works like a charm! Thank you very much for implementing this feature @qqmyers.