[Koha-devel] RFC: granular permissions

[Henri-Damien LAURENT]

Galen Charlton a écrit :
> Hi,
>
> For a customer project I've been working on an approach to make Koha's
> staff user permissions more granular.  The initial scope of the
> development is restricting access to individual items on the tools
> page, but the mechanism can readily be expanded to cover all of Koha's
> modules.
>
> My idea is to reinterpret the existing user flags to describe access
> to entire functional modules, then create a second level of
> permissions under each flag/module.  For example, associated with the
> tools flag are 15 sub-permissions, one for each tool.  If the staff
> user has permission for any of the tools, the user can get to the
> tools page, but only the ones that the user has specific access to are
> displayed.  The user flags editing page now uses a tree instead of a
> table, with a jQuery tree control to allow expanding and collapsing
> the tree of available permissions.
>
> There are two major changes to the API:
>
> * get_template_and_user and its kin now consider the value of each key
> in the flagsrequired hash, e.g.,:
>
> flagsrequired => {tools => 'export_catalog'} # must have
> export_catalog or all tools
> flagsrequired => {tools => '*'} # must have permission for at least one tool
> flagsrequired => {tools => 1} # must have permission for all tools
>
> * the set of CAN_user_XXX template variables is expanded to included
> the specific permissions, e.g., CAN_user_tools_export_catalog.  If a
> user has access to all tools, all 15 of the CAN_user_tools_YYY
> template variables are set.
>
> The granular permissions mechanism can be turned off or on with the
> CheckSpecificUserPermissions system preference; when that preference
> is off, only the top-level user flags are displayed in the permissions
> editor and are considered during authorization checks.  By default,
> this syspref is off.  However, I think the syspref should be
> temporary, and should go away after 3.2 at the latest.
>
> The specifications I followed are available on the wiki at
> http://wiki.koha.org/doku.php?id=granularpermissions.  The patches
> implementing this feature are available for review at
> http://manage-gmc.dev.kohalibrary.com/patches/granular/.
>   
Very good.
just a question.
How hard would it be to add permisions to a simple link/action ?
Say :
 I want to A to make a basket but not to close it (in Acquisition module).
Only B has the right to close a basket.
following your schema, I could add close_Basket Permission and maybe use
Template::Expr to test the permission in template.
Say :
 I want to A to be able to see a subscription but not to edit it (in
serials module). But he can receive issues.
But B has the right to edit a subscription, see a serials-collection but
not to edit.

Can it be allowed by the system ?
It seems to be.
But would require QUITE changes in our templates and codes.
And I have a big trouble :
Who, when, how will be maintained the list of all the permissions ?

My proposition is that mysql/en/permissions.sql should be authoritative.
But it should be accounted that it HAS to be translated.
And somehow it should be declared on the wiki, just as all the ccl terms
and indexes.
I think that those pages could be also good references for a handbook.
But again, very good.
-- 
Henri-Damien LAURENT


_______________________________________________
Koha-devel mailing list
Koha-devel at nongnu.org
http://lists.nongnu.org/mailman/listinfo/koha-devel