LC call numbers sort improperly in tabular displays

[Michele Morgan]

Evergreen 2.3 and earlier

In the tabular displays in the client, LC call numbers do not sort as they should by asset.call_number.label_sortkey. Instead they sort as text, even though the label class in the call number is correctly set as LC. As an example, a bucket containing three items, sorted by the call number column will show as:

HV 10.5 .E24 1991
HV 1431 .S76 1990
HV 28 .K32 K63 1988

The label_sortkeys for these call numbers are:

HV00105 E24 01991
HV1431 S76 01990
HV0028 K32 K63 01988

It's often handy to make quick reports from the item status or item bucket screens, but LC libraries can't take advantage of this if their call numbers don't sort correctly.

[Ben Shum (bshum)]

Pending verification of bug?

[Kyle Tomita (tomitakyle)]

Tested this on Master (last commit 61302b72d463d035985bc34f535606742678c758) and I am seeing similar results.

Added the same call numbers and it returns in the order
HV 10.5 .E24 1991
HV 1431 .S76 1990
HV 28 .K32 K63 1988

and not

HV 10.5 .E24 1991
HV 28 .K32 K63 1988
HV 1431 .S76 1990

which is expected.

[Kyle Tomita (tomitakyle)]

Here is a branch with a fix on working repo, user/ktomita/lp1182605-lc_call_numbers_sort_improperly

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=refs/heads/user/ktomita/lp1182605-lc_call_numbers_sort_improperly

I added a sort_value attribute to use label_sortkey.

[Kyle Tomita (tomitakyle)]

Testing workflow:
1. Added volumes with the call numbers given in bug and made sure the label_sortkey's matched. Added copies to each of them.
2. In the staff client, pulled up the item status screen (F5)
3. Entered in the barcodes for one copy of each call number.
4. Clicked on the column heading Call Number to test the sort.

[Kathy Lussier (klussier)]

Thanks Kyle! The kind folks at NOBLE tested your branch this morning on 2.4, and LC call numbers are now sorting properly. Signed off at:

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

Kathy

[Dan Wells (dbw2)]

Gave this a quick review. Looks good, but I see a couple things worth reconsidering:

1) This looks like (with one exception) a copy-paste of the render function. It's a fair bit of logic, so I'd prefer to see it abstracted out to a utility function rather than simply duplicated.

2) There is also a call number column defined later in the same file for the 'hold_columns' group. I think that should also get the sort_value treatment while we are in here (which is all the more reason to extract the logic into a function).

Thanks, Kyle!

[Kyle Tomita (tomitakyle)]

I will try and take a look at this in the coming week.

[Victoria Lewis (vlewis-q)]

Evergreen bug 1182605 was previously corrected. LC call numbers were not sorting as they should by

asset.call_number.label_sortkey. The bug was fixed, but code was duplicated in the 'call_number column' in the

'columns' group and in the 'hold_columns'group.

I abstracted the logic out of 'sort_value' and 'render' in the 'call_number' column in the 'columns' group and from

'render' in the 'call_number' column in the 'hold_columns' group to a utility function called

'sort_call_numbers_by_label_sortkey'.

Testing workflow:
1. Added volumes with the call numbers given in bug and made sure the label_sortkey's matched. Added copies to each of

them.
2. In the staff client, pulled up the item status screen (F5)
3. Entered in the barcodes for one copy of each call number.
4. Clicked on the column heading Call Number to test the sort.

This is the branch with the fix.
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/catalystit/lp1182605-lc_call_numbers_sort_improperly

[Kathy Lussier (klussier)]

Thank you for working on this Victoria! We tested the addition of the code. The LC sorting continued to work correctly in copy buckets and item status, as they did with the previous code, but it still isn't sorting correctly in the holds interfaces. We tested the xul-based Holds Pull List, the Browse Holds Shelf Screen, and the Holds screen in the patron record.

[Kathy Lussier (klussier)]

It looks like we were missing a sort value for the holds interfaces. I took what Victoria had done for the circ interfaces and replicated it for the holds interfaces to get them to sort properly too.

I signed off on Kyle's and Victoria's commits and added my own commit to fix the holds interfaces at:

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

[Remington Steed (rjs7)]

Tested and works fine in 2.5. Here's my signoff branch:

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

[Remington Steed (rjs7)]

Also, just tested it in 2.6 and works fine.

[Dan Wells (dbw2)]

Pushed to master through 2.5. Thanks to everyone involved for seeing this through!

[Don Butterworth (don-butterworth)]

We are still having problems with our Call Number display in 2.6.0. Here is an example. The first 10 copy lines seem to display okay, but go to the next 10 and there's trouble.

Title: Themelios
https://evergreen-dev.asburyseminary.edu/eg/opac/record/483948?query=themelios;qtype=title;locg=1

[Kathy Lussier (klussier)]

Hi Don,

This fix was specifically for LC sorting in staff client interfaces. It doesn't affect the public catalog display and only affected LC call numbers. It also didn't make it into 2.6 until 2.6.3. I haven't looked at this bug report closely, but maybe this is what you're seeing?:

https://bugs.launchpad.net/evergreen/+bug/1131895

Kathy