Access request : improve granting access workflow

[olivierdalang]

Hi !

The issue is that the maintainer/author isn't necessarily a CKAN user, so that it's not helpful for him/her to get a message for access requests.

I think we should use the dataset owner's email instead (the person who created the package in the first place). And if needed, we could add another field to choose which user (amongst those who have edit rights to the resources) should get the access request.

In an ideal world, all editors would get access requests emails (optionally muteable), and there would be a page in the UI showing all pending access requests.

Alternatively, if we want to keep the ability for external authors to grant access to resources, we should put a "grant access" link in the email, with some secret token, allowing to grant access without even requiring a login.

Thanks !

[espona]

Hi Oliver,

We have a different set up, for us the maintainer is the person in charge for the dataset, the contact point. I think this is the case in most CKAN instances as far as I know, I have never had such a request. Therefore change you implemented won't work for us.

The alternative you propose where you can select who to contact and also the grating token not requiring login, is indeed very interesting but it requires quite some work and I won't get resources to do it since it is not necessary for my contractor.

If you want to do an improved version of this extension, I would be glad to point users to your repository since the support I can provide is very limited.

Thanks for your interest in this extension!

[olivierdalang]

Same comment as #15 (comment) (about keeping the issue open).

What about adding a setting, that defaults to current usage, but allows to define the source of maintainer name/emails ?
Example:

# production.ini

# Ordered comma separated list of who gets the access request emails
# This first met value will be used. Can be maintainer, author, owner, admin.
# default is : maintainer,author,admin
ckanext.restricted.requests_emails_recipients = owner
# Ordered comma separated list of who gets a copy of the request emails
# All values will be used. Can be maintainer, author, owner, admin.
# default is : admin
ckanext.restricted.requests_emails_copy_recipients = admin

Potentially we could add editors, which would be all people who can edit the dataset, so the burden doesn't lie on just one person.

[espona]

It sounds fine but we cannot work on this since it is not useful for us and making such a change requires updating our running instances and testing, etc. Let us know in case you implement it so I can point users to your fork or extension.