Hi Armen: On Fri, Oct 22, 2010 at 05:50:20PM +0500, Armen wrote: > Hello List, > > in the Fundamental Scientific Library (Armenia) currently we are > implementing circulation module, and I'm facing some problems.. > > When (as an administrator) from Circulation->Register Patron I am > registering a patron, then 'Profile Group' (module Groups and > > Permissions) is not empty, and I can see patrons (dimmed) and Staff (with > active lines). So I can register a Circulator from that list. > > When as a Circulator I am trying to register patrons, then the 'Profile > Group' is empty. So i can't save any patron, being registered as a > Circulator. > > My EG verion is: 1_6_0_6. > > How to solve the problem?
The good news is that this is probably a pretty common problem. One could also say that this is probably bad news, because it makes things a little more difficult for the out-of-the-box users of Evergreen. http://docs.evergreen-ils.org/1.6/draft/html/circulation.html#patronrecords talks about registering patrons, but doesn't link to any information about what permissions are required to register patrons in various groups. Here's an attempt to supplement that. In Evergreen, permissions can be granted to individual users. In a large system, keeping track of who was been granted which privilege can quickly become daunting. To make that easier, Evergreen also enables you to grant permissions to groups to which a user can belong. A given user in Evergreen can belong to multiple groups, but the default interface in Evergreen only enables you to assign a user to a "Profile" that matches one group. Groups, in turn, can be children of other groups and inherit the permissions that are granted to the parent groups. Out of the box, Evergreen comes with "Users", "Patrons", "Staff", "Circulators", "Catalogers", and "Local System Administrators" groups. The "Staff" group inherits from the "Users" group; the "Circulators", "Catalogers", and "Local System Administrators" groups, in turn, inherit from the "Staff" group. So, when you registered your circulation user and put them in the "Circulator" group, they were granted all the permissions of "Users", "Staff", and "Circulator" groups combined. So far, so good. Now, to answer your question about why your circulation user cannot register a new patron (being blocked by the lack of an option for a profile), there are a set of permissions that control which profiles can be assigned to a new patron. The 'code' for these permissions begins with the phrase 'group_application.user'. So, checking the permission list in the database, we see: evergreen=# SELECT * FROM permission.perm_list WHERE code LIKE 'group_application%'; id | code | description -----+-------------------------------------------------+----------------------------------------------------------------------------------- 125 | group_application.user | Allow a user to add/remove users to/from the "User" group 126 | group_application.user.patron | Allow a user to add/remove users to/from the "Patron" group 127 | group_application.user.staff | Allow a user to add/remove users to/from the "Staff" group 128 | group_application.user.staff.circ | Allow a user to add/remove users to/from the "Circulator" group 129 | group_application.user.staff.cat | Allow a user to add/remove users to/from the "Cataloger" group 131 | group_application.user.staff.admin.local_admin | Allow a user to add/remove users to/from the "LocalAdmin" group This permission code corresponds to the 'application_perm' column of the permission.grp_tree table: evergreen=# SELECT id, name, application_perm FROM permission.grp_tree; id | name | application_perm ----+----------------------------+------------------------------------------------ 1 | Users | group_application.user 2 | Patrons | group_application.user.patron 3 | Staff | group_application.user.staff 4 | Catalogers | group_application.user.staff.cat 5 | Circulators | group_application.user.staff.circ 10 | Local System Administrator | group_application.user.staff.admin.local_admin Now checking the mapping of permissions to groups in the database for the "Circulator" group for these 'group_application' permission codes, we see: evergreen=# SELECT ppl.code FROM permission.grp_perm_map pgm INNER JOIN permission.perm_list ppl ON ppl.id = pgm.perm INNER JOIN permission.grp_tree pgt ON pgt.id = pgm.grp WHERE ppl.code LIKE 'group_application%' AND pgt.name = 'Circulators' ; code ------ (0 rows) So - circulators, out of the box, do not have permission to register users of any kind. Who does have this permission? Let's check: evergreen=# SELECT ppl.code FROM permission.grp_perm_map pgm INNER JOIN permission.perm_list ppl ON ppl.id = pgm.perm INNER JOIN permission.grp_tree pgt ON pgt.id = pgm.grp WHERE ppl.code LIKE 'group_application%' ; code ------ (0 rows) Ah - no group has that permission out of the box for Evergreen. So, to fix that problem, you can assign the permission to the Circulators group like so, using the ID of the Circulators group (5) and the ID of the permission code for registering patrons (126) that we had previously retrieved from the database, and assigning a depth of '2' to the permission to apply the permission at the 'Branch' level of the library hierarchy: evergreen=# INSERT INTO permission.grp_perm_map (grp, perm, depth) VALUES (5, 126, 2); INSERT 0 1 ... And that should resolve the problem for all circulators. The other option is to assign the permission manually to all circulator users that you create, but I don't think that scales particularly well. With that explanation aside, I wonder whether we should at least enable Circulators to register patrons out of the box - it seems like a serious limitation to have to overcome right out of the gate for a new adopter of Evergreen.
