ckan
Authorisation suggestion (and bug in current documentation)
Would it be possible to implement an authorisation module whereby the Sysadmin could define for their install of CKAN what rights different user types had. You would essentially have a matrix of user types in rows and rights (create, delete, edit, make public etc) in columns, and the sysadmin turns on or off the different rights for each user type.
In the perfect world the Sysadmin could create new user types, but a big step would be even being able to tweak rights for the currently defined user types (plus possibly an additional type such as Alice Heaton mentioned ckan-dev Digest, Vol 44, Issue 31 - a basic member who can create/edit/delete their own datasets (only) - I'd value that as a seperate user type over just a basic member who only gets rights to see private datasets in their organisations, no upload/edit rights).
Perhaps the module could allow for the 3 (or 4 including Alice's enhanced member role) standard user types which Sysadmin can vary permissions, plus 1 or 2 slots which the Sysadmin can customise (give a name label as well as assign permissions).
BUG: Also note that currently there is a bug in the documentation http://docs.ckan.org/en/ckan-2.2/user-guide.html#users-organizations-and-authorization states
"In the default setup, this dataset is initially private, and visible only to other users in the same organization. When it is ready for publication, it can be published at the press of a button. This may require a higher authorization level within the organization."
Suggesting there may be some differentiation in what roles can make a dataset public.
HOWEVER, as confirmed by @nigelbabu "As far as I can see, it's a bug in the documentation. Everyone who has permissions to update the datasets (admin and editors) can change the private/public flag."
This seems to be the way that most CMS systems manage user authentication these days (Wordpress for instance). It would probably be the most flexible as well. I suspect this would need non-trivial changes in how we do auth.
Note we used to have this sort of thing in the user interface (ckan-admin section).
Yes we scrapped the rights matrix because it actually was not very flexible and didn't deal with groups and organizations at all well. So we put in a plug-in system, so you can have whatever authorization system you want. You write the rules in code so that every decision can take account of any information in the database, not just a user's roles and what they are allowed from a fixed list of rights.
The default rules are based on attaching users to groups and organizations, with some common configurations settable in the config. But if these don's suit then there is no reason you couldn't introduce a plug-in to do a roles/rights matrix.
On 4 July 2014 10:40, Rufus Pollock [email protected] wrote:
Note we used to have this sort of thing in the user interface (ckan-admin section).
— Reply to this email directly or view it on GitHub https://github.com/ckan/ideas-and-roadmap/issues/63#issuecomment-48025610 .
Hi,
I know this issue is quite old, but IMHO the problem still exists.
Would it be possible at least to start allowing sysadmins to change user roles between the existing ones?
