simplified holds pull list interface does not always display all holds

Bug #1099567 reported by Kathy Lussier
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Undecided
Unassigned

Bug Description

We've seen several instances where the simplified pull list does not display all of the holds that should be pulled from the shelves. However, all of the holds are included in the report that is printed from the simplified pull list screen. Although this interface is used primarily to generate the printed report, which is working properly, it is still disconcerting to users to see a shortened version of their pull list on this screen.

I've seen this on two Evergreen servers, one is running 2.3.1 and the other is running 2.3.2.

I saw the following when using the simplified pull list for a library on the 2.3.2 server:

I retrieved a pull list that contained 141 items.

When retrieving the simplified pull list sorted by copy location and then call number label, it displayed 49 items.

I explored the possibility that a display issue with hold #50 (id 257) was causing the problem. However, I later canceled another hold on the list, reducing the hold list to 140 items. When I retrieved the simplified pull list after canceling that hold, it again displayed 49 items, but hold id was now #49 and was displaying properly. In other tests, I also grepped the id of a hold where the list stopped display, but I didn't see any apparent errors.

We also discovered that the number of holds displaying on the simplified pull list would change when the sort order was changed. In the above example, when I changed the sort order to hold id, 18 items displayed; when I changed it to sort by call number label, 99 items displayed. When I returned to sorting by copy location then call number, it was consistently 49 items for this list.

A colleague testing this list on another workstation was getting the same numbers on the list for this particular library.

We also have libraries that are displaying their simplified pull list without any problems.

I checked the JavaScript Console, but didn't see any errors for the problem pull lists that weren't also displaying for the pull lists that were generating properly. However, I have attached a screenshot showing the errors from the console.

Tags: holds
Revision history for this message
Kathy Lussier (klussier) wrote :
Changed in evergreen:
status: New → Triaged
Revision history for this message
Tina Ji (tji) wrote :

We've been testing 2.4 beta.

I coul only see 21 holds on Simplified Pull List while there there 151 lines on the default view, which unfortunately contained some repetitions, but not too many.

I tried to filter by Shelving Location on the Simplified List. I still saw 21 holds. When I printed from the screen, I got 36 holds printed. No repetition.

Tina
Sitka

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

Evergreen Indiana consortium is on 2.7.2 and we have a reported instance of this issue. Library gave screen shots showing 36 holds on the "On Shelf Pull List" but when opening the Simplified Pull List Interface only 24 holds are displayed. Further detail from library:

"When the simplified list was printed with "print pull list" button, 36 items printed. Apparently, this number discrepency between the first holds list and the simplified view happens fairly frequently athough with different results. Sometimes only 1 item is missing from the simplified list view and doesn't print at all but the person processing the list can figure out which one is missing from the first list."

So the printed version sometimes contains all of the initial list (On Shelf Pull List) , and sometimes is off by a hold while the simplified version still is short by several holds.

Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

OK, for comment #3 above please disregard the last sentence / paragraph as I misinterpreted the comments from site!

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

refers to XUL interface

Changed in evergreen:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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