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."

Start with the authorization proposal in the issue and the linked CKAN 2.2 user-guide section on users, organizations and authorization. Verify the documented claim against the stated admin/editor behavior, then clarify the desired role and permission matrix before defining what implementation and documentation changes would count as done.

Written by the indexing model from the issue text.