Patron Search filtered on Staff Perm. Grp. returns incorrect results

Bug #1497322 reported by Deborah Luchenbill on 2015-09-18
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.0
Medium
Unassigned

Bug Description

In the staff client, when doing a search filtering only on Library and on Main Profile Permission Group, when I search on the general permission Staff, it returns a list of patrons who have totally different permission groups--all regular Patron permissions.

Our permission chart starts with Users, with Patrons and Staff under that, then further subdivided into Patron groups and Staff groups. Searching on any of the other permission groups returns correct results--or the pop-up message saying there are no patrons in that group.

We're on 2.8.2.

Revision history for this message
Kathy Lussier (klussier) wrote :

Confirming with the additional comment that, in my testing, I also had problems with the child permission groups retrieving accurate results. There didn't seem to be any discernible pattern to the permission groups that were being retrieved.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Jane Sandberg (sandbej) on 2018-03-26
tags: added: patron
Revision history for this message
Jane Sandberg (sandbej) wrote :

Confirmed that this is still a problem in Webby 2.12

tags: added: webstaffclient
Revision history for this message
Jason Boyer (jboyer) wrote :

What's happening is that the number of the group id is changed to text and compared via regex to '^X' where X is the id of the permission group selected from the dropdown. Since ^ means "starts with" selecting any single-digit group id will include the expected group X, but also X0 - X9, X00 - X99 and so on. Since the numbers really mean nothing as far as relations are concerned, it looks completely random.

The ideal fix for this would be to stop comparing the profile field with a regex and instead use 'in permission.grp_descendants(X)'. This way you'd be able to choose a specific group like Resident or a higher level group like Staff, Patron, Vendor, etc.

Revision history for this message
Jason Boyer (jboyer) wrote :

I finally found time to implement what I was referring to in comment 3. This branch allows you to choose a profile and if it has no descendants you will only receive users in that profile. You can also now choose parent groups to search more broadly (All groups under Circulators, Staff, etc.)

Here it is: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp14973322-patron-search-grp

To test
Search for users by last name (and / or first) and do not select a profile, take note of results
Select the top of your permission group tree (Users, likely) and search again, results should be the same.
Select a group further down the tree (Circulators, Administrators, Patrons, etc.) and repeat the search, there should only be results from that group and its descendants.
Finally, select a group with no child groups. Results will only be in that specific group.

tags: added: pullrequest
Revision history for this message
Terran McCanna (tmccanna) wrote :

Thank you, Jason!!!!!!

We have a "Staff" parent in our hierarchy, and to get all staff for a location, I just entered the state and left the name fields blank.

********************

I have tested this code and consent to signing off on it with my name, Terran McCanna and my email address, <email address hidden>.

tags: added: signedoff
Revision history for this message
Galen Charlton (gmc) wrote :

I've pushed a branch called user/gmcharlt/lp1497322_further_testing that includes a unit test as a well as a follow-up that allows search on /only/ the profile. Leaving open for further testing; note that as mentioned in my follow-up, I suspect that we may want to mark the permission.grp_descendants() function stable.

Changed in evergreen:
milestone: none → 3.1.2
Revision history for this message
Mike Rylander (mrylander) wrote :

Because every user is in a group that is a descendent of the top of the group tree (normally "Users"), we could make the group selector non-nullable and default to users and then use the JOIN syntax rather than the WHERE syntax. This would remove the chance of evaluating the function more than once (re marking the function STABLE) and simplify the function as a whole. Group search would then parallel home library search.

This would require forcing use of the top of the org tree in the case of a search from the XUL client that didn't supply a group, for compatibility. That's a simple matter. However, it would mean that multi-rooted trees would not be directly supported in the XUL client, and would produce undefined results.

(NOTE: Marking the function STABLE does give the database the option of only running the function once, but does not force that. The projection of the function's output as a relation via JOIN will restrict it to a single evaluation, however.)

Thoughts?

I B (iboynton) on 2018-05-09
Changed in evergreen:
assignee: nobody → I B (iboynton)
Revision history for this message
I B (iboynton) wrote :

After some testing, it's working fine

Revision history for this message
Chris Sharp (chrissharp123) wrote :

We've tested Jason's fix but balked at implementing it on our production server pending decisions on the questions Mike brought up in comment #7. Can we consider Galen's last branch "final", or do we anticipate something changing?

Thanks,

Chris

Galen Charlton (gmc) on 2018-05-21
Changed in evergreen:
assignee: I B (iboynton) → nobody
Revision history for this message
Mike Rylander (mrylander) wrote :

Chris, unless you're hitting performance issues, I'll withdraw my suggestion for now and we can consider it a potential future improvement once XUL is out of the way.

Revision history for this message
Dawn Dale (ddale) wrote :

This appears to be working as expected. Search only returned patrons with the user profile chosen for the search.

Revision history for this message
Dawn Dale (ddale) wrote :

I have tested this code and consent to signing off on it with my name,
Dawn Dale and my email address, <email address hidden>

Revision history for this message
Jason Boyer (jboyer) wrote :

I've also tested Galen's branch and do appreciate the ability to search by profile alone. Here's a signoff for that branch too. Also, many thanks for adding the live tests; my comfort with test writing is currently limited to pgtap.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1497322_further_testing_signoff

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Mike Rylander (mrylander) wrote :

Picked into master, 3.1 and 3.0. Thanks, Galen, Dawn, and Jason!

Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers