Web Client: Patron Search at time of hold placement not retrieving all patrons

[Terran McCanna]

We're seeing a mismatch between the list of patrons retrieved from the search form that pops up at the time of hold placement and the regular search form.

On demo.evergreencatalog.com with the Concerto data, searching for all patrons named 'smith' pulls up 11 patrons on the normal search but only 10 in the search at hold placement time. The patron Jane Smith will not come up in the pop-up search either by name or by barcode (12345) although if the barcode is entered directly into the 'Place hold for patron by barcode:' box then it retrieves with no problems.

With a larger data set like ours, this is even more problematic - searching for patrons with the last name Keane in our database, for example, pulls up 61 patrons in a regular search, but only 28 in the pop-up search.

[Kathy Lussier (klussier)]

I noticed that Jane Smith has CONS as her home library. Is it possible that it's not displaying patrons whose home library is not an eligible pickup location? I'm not saying it's a good thing, but just trying to pinpoint the problem.

In the example that used production data, it seems unlikely that 33 of those patrons have a home library that is not a pickup library. Have you verified that all the limiters are the same? When I use this feature, I keep forgetting to change the scope of the search to the entire consortium. Include inactive is another one that sometimes trips me up.

[Terran McCanna (tmccanna)]

I noticed that too - changing CONS to a valid home library on Jane Smith didn't help. Her account is expired, but other accounts that did come up were also expired, and renewing her account didn't help. I also checked that she wasn't barred, that she was active, I cleared off her fines, removed all the alerts, changed her dob so she was no longer juvenile, and everything else I could think of.

In the example that used production data, none of the patrons I checked had any problems with their pickup libraries. I triple-checked that the search limiters were the same as well (consortium level, including inactive).

I also confirmed on both demo and on our server that the problematic accounts could successfully place holds with no errors or alerts if their barcodes were entered directly instead of being searched for.

[Mike Rylander (mrylander)]

Terran, if I understand what Kathy was asking, I she was curious if the home library selector in the modal popup for searching on users was at something other than the top of the org tree or the "include inactive" checkbox was selected, effectively limiting the search range.

For instance, if I expand the search form and set the range to CONS and check "Include Inactive?" I get 11 users on demo.evergreencatalog.com, as you were expecting to see.

[Kathy Lussier (klussier)]

Actually, there are 12 users with the name 'Smith' when the 'include inactive?' flag is selected. I'm seeing the same behavior that Terran saw where Jane Smith's record isn't being retrieved. I originally thought it was explained by the home library being set to CONS, but, now that Terran has changed it to BR1, I still can't get it to retrieve from the place hold form.

[Terran McCanna (tmccanna)]

Right - now I'm seeing 11 results but it should be 12. I'm not sure where the 12th one came from since I wasn't seeing it earlier. Jane Smith still isn't being retrieved.

As another test, I just created a new account for Bob Smith (999999) and it became immediately available to the pop-up search results.

[Andrea Neiman (aneiman)]

Tried this on another demo system running 3.0.0 + Concerto data and I was unable to get this to happen -- I tried several different search combos & in all cases got the exact results set in regular Patron Search as I did in the Search from Place Hold.

[Terran McCanna (tmccanna)]

Still seeing this problem on 3.0.1 with real data - search for last name "dalbert" in regular search turns up 10 results, search in this interface only turns up 4.

[Terran McCanna (tmccanna)]

Still broken on 3.0.2.

[Blake GH (bmagic)]

We don't get any results when using this feature unless we search consortium scope. When searching the system level, we get 0 results.

[Terran McCanna (tmccanna)]

We get system-level results *if* it includes a system that shows results when scoping the whole consortium.

For example, if I do a regular patron search for Dalbert, I get 5 people in ARCPLS and 5 in GCHR.

If I do a patron search on the holds page, I only get 4 GCHR regardless of whether I scope to PINES or GCHR. If I scope to ARCPLS, I get 0.

It does not appear to be filtering by active/inactive, expired, barred, notes, alerts, or anything else I have thought of checking.

[Kathy Lussier (klussier)]

I don't know why I changed this from Confirmed to New back in October. Changing it back to Confirmed.

[Kathy Lussier (klussier)]

Adding some notes from bug , which was marked as a duplicate.

Bob Wicksall and some others are reporting that they are getting no results at all, while Terran and I are able to retrieve some, but not all, results.

Bob and I have both reported seeing the following in the browser Console:

TypeError: Cannot read property 'map' of undefined
    at patron_search.js:261
    at Object.q [as forEach] (angular.js:325)
    at Object.service.localFlesh (patron_search.js:257)
    at patron_search.js:704
    at angular.js:16785
    at m.$eval (angular.js:17994)
    at m.$digest (angular.js:17808)
    at angular.js:18033
    at f (angular.js:6045)
    at angular.js:6324

Bob also noted the following:

"My test was with real data upgraded from 2.10 to 3.0.2. No matter how I scope the search I get 0 results.

The error above seems to happen in every case multiple times. It corresponds to the number of patron results that should have returned. If an org unit has 23 Smiths there will be 23 errors in the console."

[Kathy Lussier (klussier)]

Oops! I omitted the bug number in my above comment. It was bug 1736200 that was marked as a duplicate.

[Scott Thomas (scott-thomas-9)]

We just upgraded and are getting no results. I confess to being irritated because our consortium paid for this development. It performed fine in testing. I hope it is fixed soon.

[Terran McCanna (tmccanna)]

Scott - we ended up hiding the button in our implementation because the results were so poor.

[Galen Charlton (gmc)]

A patch is available at the tip of the user/gmcharlt/lp1724052_sth_with_patron_stat_cats branch in the working/Evergreen repository:

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

[Cesar V (cesardv)]

Tested Galen's patch, works fine for me. Signing off here:

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

[Bill Erickson (berick)]

Confirmed bug and fix. All tests described passed. Double-checked for other code that might be depending on data that's loaded different now and confirmed we're in the clear.

Pushed to master and rel_3_0. Thanks to you all!