Restrict certain groups from permission profile filter choices

[Ben Shum]

In our consortium, we use many levels of permission groups, specifically to sequester our school library patron types from public library patrons, and vice versa. So a public library staff member can only create/edit a public library user, etc.

With the addition of the permission profile filter choice on search, it gives you the option to search in groups that you may or may not be able to edit said users. This does not mean you couldn't check things out to them or not, but generally our libraries try to avoid picking the "wrong record". With user groups being shown in a purely alphabetical format, it might be less clear which user groups are being used by your library or not.

Two ideas:

1) Restrict the permission profile filter so that it only shows a list generated based on which groups your staff account has access to create/edit similar to how patron registration options currently work. If desiring to search beyond defined permission groups, they can still use a default of searching every type of patron in the system.

2) Apply a new sorting method whereby parents/children groups are clearly identified. So that way you can quickly select from the dropdown based on which groups they know is theirs. Based on our consortium, such a list might be like:

Users
    - Public Patrons
        -- Adult
        -- Child
        -- Senior
    - School Patron
        -- Grade 1
        -- Grade 2
        -- Grade 3
    - Staff
        -- Acquisitions
        -- Cataloger
        -- Circulator

Thoughts or opinions?

[Thomas Berezansky (tsbere)]

I would like to vote against #1.

I would like to add a #3 that may be best done in conjunction with #2:

Add an OU setting for "Hide these permission groups from patron search" that would be a comma-delimited list of IDs.

If #2 is done as well then it would hide those IDs *and* all descendant IDs. That would allow a simple "For public libraries hide the School Patrons subtree and vice-versa" rule to be entered without needing to worry about if additional public/school groups are added later.

[Jennifer Pringle (jpringle-u)]

#2 is fixed in the web client - the profile group drop down in patron edit and patron search displays based on your permission tree (and are indented to indicate children)

#1 I think is partially resolved by the addition of the Permission Tree Display Entries functionality (Administration -> Permission Tree Display Entries).

This functionality only affects the drop down menu in the patron registration/edit and not in the patron search. Further discussion is likely needed of whether this functionality should be extended to the drop down in patron search.