webclient: Call number sorting needs to be by sortkey

Bug #1654529 reported by Kathy Lussier
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
3.3
Fix Released
Medium
Unassigned
3.4
Fix Released
Medium
Unassigned

Bug Description

While testing bug 1653001, I noticed that call number sorting in copy buckets and the transit list are sorting by label, not by the call number sortkey. I tested the display of copies with the following LC call numbers: HV 10.5 .E24 1991, HV 28 .K32 K63 1988, and HV 1431 .S76 1990.

The call numbers are sorting as:
HV 10.5 .E24 1991
HV 1431 .S76 1990
HV 28 .K32 K63 1988

When the expected sort order is:
HV 10.5 .E24 1991
HV 28 .K32 K63 1988
HV 1431 .S76 1990

tags: added: sorting
Revision history for this message
Rosie Le Faive (rlefaive) wrote :

This (I think it's the same bug) also affects the Shelf Browser (in the public OPAC). The sort is not parsing LC call numbers numerically.

It's sorting
 QD305.T45T55 2013
 QD31.2.A75 1989

This affects both 3.2.0 and 2.12.

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

Hi Rosie,

I'm fairly sure that the Shelf Browser sorts by sortkey, but there may be a problem with the way the sortkey is generating.

One thing you should check is that the label_class field in asset.call_number is set to the LC classification scheme (id 3). We've seen problems with call number sorting in Shelf Browse when catalogers didn't realize they needed to set the Classification scheme while cataloging.

If the classification scheme is correct and the call numbers still sort incorrectly, you can get a better idea of why it's mis-sorting by looking at the label_sortkey field in asset.call_number.

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

Adding a note that I tried these specific call numbers on the community demo server. With the classification scheme set to LC, I saw the following in the call_number sortkey field:

QD305.T45T55 2013 - QD0305 T45 T55 02013
QD31.2.A75 1989 - QD00312 A75 01989

The call numbers did sort as expected in the shelf browse. I suspect the issue you're seeing is that the LC class scheme wasn't applied to one or both of the call numbers.

See - http://mlnc4.noblenet.org/eg/opac/record/253?query=kathy%27s%20adventures;qtype=keyword;locg=1;detail_record_view=0;expand=cnbrowse#cnbrowse

Revision history for this message
Michele Morgan (mmorgan) wrote :

Blowing off the dust on this and setting to Confirmed. Call numbers are sorting by label rather than label sortkey in copy buckets and transit lists. Tested this on Evergreen 3.2.8.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kyle Huckins (khuckins) wrote :

I've also confirmed the issue. It appears this may be a limitation with the Grid, rather than the interface itself - I'm thinking an option to sort by sortkey(programatically looking for columns with the same name as the expected column, but appended with _sortkey) would be the way to go. Looking into how to implement this now.

Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Revision history for this message
Kyle Huckins (khuckins) wrote :

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1654529-callnumber-sorting-by-sortkey

I've pushed a branch here to resolve the issue, taking a cue from how the Holds Pull List handles it.

Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
tags: added: pullrequest
Revision history for this message
Kate Coleman (katecoleman) wrote :

I changed call numbers for items in the sandbox server to match those in the examples above and they are still sorting incorrectly as in the first example. I tested it with and without spaces as well.

Revision history for this message
Remington Steed (rjs7) wrote :

Kate, I just found that the HV call numbers that were in the "Call Number Testing" copy bucket on the sandbox server both had the call number classification of "Generic". When I changed them both to "Library of Congress", then the copy bucket sorted them correctly. (Thanks to Kathy's clue in comment #3.) Now I'm seeing this correct order:

HV 28 .K32 K63 1988
HV 1431 .S76 1990

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

We (mostly Elaine Hardy) tested as well, and confirmed Remington's feedback that as long as the Library of Congress Call Numbers use the LCC schema, they sort correctly.

My sign-off branch at:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp165429-callnumber-sorting-by-sortkey-signoff

tags: added: signedoff
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Pushed to master, 3.3 and 3.4 - thanks Kyle and all!

Changed in evergreen:
milestone: none → 3.5-alpha
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
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.