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

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.

Confirmed that this is still a problem in Webby 2.12

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.

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.

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>.

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.

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?

After some testing, it's working fine

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

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.

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

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

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

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