Sorting Improvements for Web Client Holds Pull List Printing

[Joan Kranich]

Evergreen Release 3.0.3

Printing the Holds Pull List by clicking the button Print Full List results in a list sorted by Shelf Location (Shelving Location) but not by Call Number.

Clicking the Print Full List should result in a list sorted by Shelving Location and by Call Number.

I can add a line to the Print Template Hold Pull List to order by volume.

<tr ng-repeat="hold_data in holds | orderBy : ['copy.location.name','volume.label']">

This will sort by location and call number, however it would be very helpful if it was not necessary for libraries to add this line.

Some libraries also need the list to sort by call number prefix along with call number.

[Jeanette Lundgren (jlundgren)]

CW MARS is contracting with Catalyte to work on this bug.

On the Holds Pull List, the Call Number is the Call Number Label field which includes call number prefix, call number, and call number suffix.

When you click the Print Full List button on a very large list, it displays in a seemingly random order (see attached from test library with over 400 holds).

The Call Number in the Print Full List is the call number (no prefix or suffix).

We would like the print full list function to perform a default sort in the following order:
     -shelving location
       then
     -call number label (or call number prefix then call number then suffix))

Desired Sort Example:

Shelving Location Call Number
A/V Audio CD 599 CASEY
A/V Audio CD BURKE
A/V Audio CD CONNELLY
A/V Audio CD GABALDON
A/V Audio CD ROCK FOLLOW
A/V Audio DIGITAL PLAYER HAWKINS
A/V Audio DIGITAL PLAYER HOFFMAN
Closed Stacks CS 728.6 RUTSTRUM 1972
Closed Stacks CS OVERSIZE 629.2 CADILLAC 1967-1989
Closed Stacks OVERSIZE 629.287 M9192me 1974-79
Fiction FICTION CARLSON
Fiction MYSTERY COTTERIL
Fiction SCI FI DELANY
Fiction THRILL COOK
Note: currently the prefixes in the list above (CD, DIGITAL PLAYER, CS, OVERSIZE, MYSTERY, SCI FI, THRILL) do not display in print full list.

[Kathy Lussier (klussier)]

I just want to add a reminder that when sorting by Copy Location, it needs to go by the ordered designated in the Copy Location Order Admin interface, not strictly alphabetical (unless, of course, no order had been specified in that interface.)

[Joan Kranich (jkranich)]

The library used for comment #1 pull list: Sample_hold_print_pull_list_not_sorting.pdf has locations in alphabetical order in the Copy Location Order Admin interface.

[Kathy Lussier (klussier)]

Yes, I figured it was. Basically, if no copy location order is set, this interface shows everything as alphabetical. I added that reminder primarily so that the developer wouldn't miss it since not everyone knows it is available.

[Kyle Huckins (khuckins)]

Looking at this, I want to confirm a few things:

1. Do we want to set the default template for the Hold Pull List to have that orderBy parameter, so that libraries don't have to, or was a different method intended?
2. Does anyone in the community think it be worth adding YAOUS for determining if a library wants to order by Prefix - CN - Suffix vs just the Call number itself? My inclination to to just go with Copy Location, Prefix-CN-Suffix, but it sounds like some libraries would want just Copy Location followed by CN.

[Joan Kranich (jkranich)]

Yes, we would like the default template for the Hold Pull List to have the orderBy parameter to sort by Copy Location, Call Number Prefix, Call Number, and Call Number Suffix. For items without a prefix the sort would default to Copy Location and Call Number.

We do not need a YAOUS. The sort should work for all libraries without a setting.

On the Hold Pull List screen, there is a column for Call Number Label. Our understanding is that the Call Number Label includes Call Number Prefix, Call Number, and Call Number Suffix.

[Kyle Huckins (khuckins)]

I've pushed a branch here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1749502-holds-pull-list-printing-order

From my understanding of shelf location positioning in the code, when no order has been defined in the Copy Location Order Admin UI, it will default to alphabetical. Because of this, it seemed like the best way to handle it was to ensure we have the acplo accessible while fleshing holds via the holds service.

[Joan Kranich (jkranich)]

Evergreen release 3.0.7

I've tested the branch in #7.

We continue to have a problem with the sorting of the Holds Pull List for Hold requests using Print Full List.

Results of a pull list with 187 Holds:
List is not in Shelf Location order. Order is random.
(Locations are in order in the Copy Location Order Admin interface.)
List is in Call Number order.
Prefix does not display in the list and therefore is not in Call Number Prefix order.

Results of a pull list with 43 Holds:
List is in Shelf Location order and Call Number order.
Prefix does not display and therefore is not in Call Number Prefix order.

[Kyle Huckins (khuckins)]

I've pushed up a patch for prefixes not displaying, and rebased to the latest master. Still doing some local testing with more copies just to be sure, but this should do the trick.

[Joan Kranich (jkranich)]

Evergreen release 3.0.8
Browser Chrome
Web Client

I tested again Print Full List on the Pull List for Holds Requests in the Web Client.
The Call Number Prefix and Call Number Suffix do not display on the printout.

This makes the sorting by Call Number to look out of order.
The list is actually sorting by Prefix but because the Prefix does not display the displayed Call Number seems out of order.

I've attached a list from Print Full List and the same list printed using Print Full Grid which does display the Call Number Prefix and Call Number Suffix as an example.

[Jason Stephenson (jstephenson)]

I added my sign off to Kyle's commits on his previous branch and added an additional commit to print the call number prefix and suffix so that the sorting is show to be obviously working. It also seems useful to print the call number prefix and suffix as they often hold useful location data.

The branch is user/dyrcona/lp1749502-hold-pull-list-printing.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1749502-hold-pull-list-printing

[Galen Charlton (gmc)]

It looks like that the sorting is not taking the call number (or affix) sortkey into account. Is this intentional?

[Jason Stephenson (jstephenson)]

Galen, I didn't think of it and Kyle originally used just the prefix. It should probably be changed to use the sort key.

[Jason Stephenson (jstephenson)]

Interestingly, the original sort uses the call number label and not the sort key. I've added another commit to use the sort key for all 3 fields: prefix, label, and suffix. It's the same branch as comment #12.

I'm also confused on how it worked with just the prefix and suffix. I'm removing the pullrequest tag briefly while I look at my most recent changes.

[Jason Stephenson (jstephenson)]

So, we tried that change and it no longer sorts correctly. I did not look into what the problem was.

I have dropped that additional commit and force pushed over the previous branch. I am readding the pullrequest tag.

If someone else wants to tackle it, feel free.

[Joan Kranich (jkranich)]

Evergreen Release 3.0.11 on a test server with a few additional patches.
Browser Chrome

The branch in comment #12 is working well for us. I've tested a variety of pull lists with and without prefixes/suffixes and also the display of the part field. It all looks good and sorts correctly.

[Evergreen Bug Maintenance (bugmaster)]

To further reply to Galen's comment #13, I believe that the sortkey fields are only truly useful in the database. As I mentioned in comment #16, I could not get sorting to work in the web client using the sortkey columns. This may pose problems for LC and similar call numbers.

If it is imperative that the sortkey columns be used, then someone smarter than I will have to take this on.

[Jason Stephenson (jstephenson)]

I am removing the pullrequest and signedoff tags and adding the needsrepatch tag.

After implementing this in production, we found that the changes to holds.js has the unintended consequence of limiting a patron's holds view in the web staff client to only those holds that have a current_copy assigned.

[Josh Stompro (u-launchpad-stompro-org)]

I saw the same issue that Jason mentioned in comment #19.

Wrapping the hold.js section in the "if(hold.current_copy() .*" block above that section seems to fix the problem with holds with no targeted copies being ignored. There was a console error about "hold.current_copy() being null.

I think I have this all working. Sorts by location order if set, then by location name(for the case when location order isn't used), then by Call Number prefix sortkey, then call number sortkey, then call number suffix sortkey.

I made one change in the interest of saving space, combining the prefix, call number and suffix in one column.

I also don't love the default order of the columns. I think it makes more sense to follow the sort order, I'm not sure why the hold type is the first item. But I don't actually use the list to pull items so maybe the Type, Title, Author... order is more effective?

working branch at
user/stompro/lp1749502-hold-pull-list-printing
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1749502-hold-pull-list-printing

Working branch at

[John Amundson (jamundson)]

Thanks for your work on this, Josh.

This is a giant step forward, but I'm still seeing one issue with sort order.

Title, Metarecord, and Part holds all sort as expected.

Copy-level holds, however, are pushed to the bottom of the printout and affix IDs appear instead of labels. I've attached a screenshot of the print preview.

FWIW, the XUL client also printed in a similar order by default, (starting with Title, Author, etc). I personally agree with you, though, and printing the results in sort-order makes way more sense, (location, call number attributes).

(PS Having the prefix and suffix in the same column as the Call Number on the printout makes a lot of sense).

[Josh Stompro (u-launchpad-stompro-org)]

Hmm, the same thing happens for force holds, but not for volume holds.

So maybe wrapping the call number affix and location position code in a check to see if it isn't already fleshed fails for those, maybe copy and force level holds get the current_copy fleshed automatically because the hold target = current_copy?

I'll test and see if that is it.
Josh

[Josh Stompro (u-launchpad-stompro-org)]

That seems like it is it. The call number affixes are grabbed correctly after that is fixed.

I forced pushed and update to my previous branch.

Josh

[John Amundson (jamundson)]

Okay. I've tried and tried and haven't been able to find anything this breaks, (we had the initial branch on production for a minute, and let me tell you - seeing partial hold lists changes a person), so I'm adding my signoff.

Thank you so much to everyone involved with this fix! Our libraries will appreciate it.

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

[Jason Stephenson (jstephenson)]

Thanks everybody! I meant to push this during bug squashing week, but it slipped through the cracks. Thanks to John Amundson for reminding me about it.

I pushed it to master, rel_3_2, and rel_3_1.

[Josh Stompro (u-launchpad-stompro-org)]

It looks like there is a bug with printing the pull list twice in a row. The second time the list is printed, the call number affixes don't get populated and are printed as their ID numbers.

IRC Discussion
http://irc.evergreen-ils.org/evergreen/2019-03-20#i_399362

Josh

[John Amundson (jamundson)]

FWIW, I can't seem to duplicate this issue on the test server I used to perform my testing a couple weeks ago.

1. Wait for Pull List to load
2. Click Print Full List
3. Verify the pull list looks good. Close print dialog
4. Click Print Full List
5. Verify the pull list looks good. Close print dialog.
6... and so on: repeat

(And honestly, even if I could, I would be in favor of keeping this fix and opening up a new bug for the repeat printing issues. I feel like it would be rare for a pull list to be printed in succession).

Evergreen 3.2.4ish
Google Chrome

[Josh Stompro (u-launchpad-stompro-org)]

John, I also cannot replicate the bug on my local test system running 3.2.3. Although I do get strange results when I double/triple click on the print full list button. But I could replicate it when using the test system that Jason Etheridge had setup.

I agree that this shouldn't cause a revert. I'll start a new bug for this one. Bug 1821179.

Josh