ckan / ideas

[DEPRECATED] Use the main CKAN repo Discussions instead:
https://github.com/ckan/ckan/discussions
40 stars 2 forks source link

Advanced dataset sharing / visibility extension #235

Open pdekraker-epa opened 5 years ago

pdekraker-epa commented 5 years ago

The base CKAN permissions and roles represent a simple use case that is very effective in many situations. There are many cases however where something more flexible / granular is desirable. This has led to a variety of extensions adding different functionality: ckanext-collaborators ckanext-restricted ckanext-resourceauthorizer ckanext-privatedatasets

Some work at the resource level, others at the dataset. Some work by users, others by users and groups. Some only expand access while others include editing. I think an advanced permissions extension unifying all the functionality would be a good goal.

A potential implementation would be an access control list for each dataset with the options of: admin - edit data, metadata and user roles editor - edit data and metadata viewer - view data and metadata metadata only - view description and metadata - would need to request access to the data hidden - dataset not visible / searchable by the users(s) resource specific - access determined at the resource level using a similar set of options

The lists should allow entries for individual users or organizations, so one could quickly share a private dataset with a second organization in a few clicks. If a user and their organization are both in the list the user would take precedence. I have used resourceauthorizer for similar functionality, but the action needs to be repeated for each resource.

boranin commented 9 months ago

Extending the current dataset permission/sharing is a great idea that is grounded in real-life requirements. CKAN, as it is now, is useful in open data-sharing situations and not so much in situations when datasets (or resources) need to be shared selectively. There are many examples of where CKAN wouldn't work as it is now (including available extensions). For example, a scientific org has many teams, some working on commercial projects, some on projects that can make their data open. The commercial data can be made visible only to some teams, not all and the data from open projects should be made available to all from the organisation, but not made public. However, the presence of both, commercial and open data can be communicated to the public as some (or all) of the data can be shared upon request (and signing confidentiality agreements). In this case, ideal situation would be if dataset metadata is made public, a form for data requests is available, and resources of both types of data are shared between selected teams and internal and external contributors. This particular scenario could be put in place using ckanext-resourceauthorizer but that extension does not work with the latest CKAN. I have lately witnessed many calls by the main contributors for "blue-sky" type conversations (what do we do next with CKAN?) while the basics, like dataset and resources level permissions, easy to use SSO (without the need to become SAML2 expert) are minimal and prevent organisations from using CKAN. In my view, the core developers, as developers, do not have a good insight into what the greatest number of orgs really need when it comes to data cataloguing. Hence the calls for blue sky thinking instead of calls for making the platform feature-rich and (ordinary org) user-ready.