IMHO, just document it. I don't have any expectation that a "Circulator" should be able to register patrons (and they certainly should *not* be able to register staff). To restate the problem, if you give circulators that permission, then I think we'd need a new group created that doesn't have it matching the old permissions.
In particular this differentiation is common at libraries that have volunteer or work-study circ staff, or where patron membership requires formal criteria be met (like local residence or group affiliation), or where account initialization has non-negligible costs (e.g., expensive ID cards). --joe On Fri, Oct 22, 2010 at 9:36 AM, Dan Scott <[email protected]> wrote: > 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. >
