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

Bug #1724052 reported by Terran McCanna
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned

Bug Description

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.

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

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.

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

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.

Revision history for this message
Mike Rylander (mrylander) wrote :

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.

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

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.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Terran McCanna (tmccanna) wrote :

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.

Kathy Lussier (klussier)
Changed in evergreen:
status: Confirmed → New
Revision history for this message
Andrea Neiman (aneiman) wrote :

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.

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

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.

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

Still broken on 3.0.2.

Revision history for this message
Blake GH (bmagic) wrote :

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

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

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.

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

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

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

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

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 3.0.3
Revision history for this message
Kathy Lussier (klussier) wrote :

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

Revision history for this message
Scott Thomas (scott-thomas-9) wrote :

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.

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

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

Galen Charlton (gmc)
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Revision history for this message
Galen Charlton (gmc) wrote :

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

tags: added: signedoff
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
tags: added: pullrequest
removed: signedoff
Revision history for this message
Cesar V (cesardv) wrote :
Changed in evergreen:
milestone: 3.0.3 → 3.0.4
Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

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!

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.