[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Koha-devel] RFC: granular permissions
From: |
Galen Charlton |
Subject: |
Re: [Koha-devel] RFC: granular permissions |
Date: |
Tue, 8 Apr 2008 10:06:18 -0500 |
Hi,
On Tue, Apr 8, 2008 at 9:43 AM, Henri-Damien LAURENT
<address@hidden> wrote:
> Very good.
> just a question.
> How hard would it be to add permisions to a simple link/action ?
I don't think this will be hard to do - just time consuming, given the
number of functions that Koha users may want to have sliced and diced.
For most scripts, the pattern is to call get_template_and_user very
early; I think that will change so that first the script determines
what operation is to be done, then set up the flagsrequired hash
appropriately.
> 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.
The way I've designed it, you don't need to use Template::Expr; there
would a separate binary CAN_user_XXX_YYY for each specific permission.
I think most of the work of implementing specific privileges for
acquisitions, circulation, and cataloging will be carefully adjusting
the templates so that a user with limited privileges doesn't get
dumped into the login page unexpectedly.
> 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.
Agreed.
> But it should be accounted that it HAS to be translated.
Agreed. I added a mysql/fr-FR/1-Obligatoire/userpermissions.sql as a
placeholder in parallel with the existing userflags.sql, but I don't
view that as a long-term solution. I'll think about it and see if I
can come up with a general approach for exposing strings that are
stored in the database to the translation mechanism.
> And somehow it should be declared on the wiki, just as all the ccl terms
> and indexes.
Agreed. I propose a few conventions for the permissions codes (which
I admittedly haven't been 100% consistent about in the list for
tools):
* view_XXX = view record type XXX
* edit_XXX = edit record type XXX
* first word or word group in the code is a verb
* don't put in a negative, e.g., don't have something like
'cannot_edit_orders'. A permission should be a positive grant of a
privilege.
Regards,
Galen
--
Galen Charlton
Koha Application Developer
LibLime
address@hidden
p: 1-888-564-2457 x709