[OPEN-ILS-GENERAL] We have a problem "Profile group"

[Joe Atzberger]

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 <dan at coffeecode.net> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20101022/b8d1a8f2/attachment-0001.htm