Bug 4265 - Sorting by call number in OPAC is slightly off
Summary: Sorting by call number in OPAC is slightly off
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: Magnus Enger
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-25 02:11 UTC by Magnus Enger
Modified: 2012-10-25 23:09 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot showing sort in HEAD (38.67 KB, image/png)
2010-02-25 14:11 UTC, Chris Cormack
Details
Fixes padding of short callnumbers and Bib-1 attribute for sorting (1.97 KB, patch)
2010-02-25 21:11 UTC, Chris Cormack
Details | Diff | Splinter Review
Small script used to test the proposed changes to C4/ClassSortRoutine/Dewey.pm (1.96 KB, text/plain)
2010-02-25 21:13 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:25:08 UTC


---- Reported by magnus@enger.priv.no 2010-02-25 14:11:55 ----

Created an attachment
Screenshot showing sort in HEAD

Sorting by call number in the OPAC gives this sort order: 

1. "346.04 Les"
2. "346 Les"

Thanks to Elin Strand who spotted this.



---- Additional Comments From magnus@enger.priv.no 2010-02-25 14:21:47 ----

Here's cn_sort and cn_source for the two records in the screenshot: 

mysql> select cn_sort, cn_source from items;  
+--------------------------+-----------+
| cn_sort                  | cn_source |
+--------------------------+-----------+
| 346_LES                  | ddc       | 
| 346_040000000000000_LES  | ddc       | 
+--------------------------+-----------+



---- Additional Comments From jwagner@ptfs.com 2010-02-25 14:54:15 ----

We have seen this with LC call numbers, and believe the problem is in the padding routine that creates the cn_sort field.  The system pads only the first segment of the call number, not all segments.  So the first segment of cn_sort sorts OK, but the rest don't.  In the example given, if it were properly padded, the fields should look something like:

346_0000000000000LES




---- Additional Comments From magnus@enger.priv.no 2010-02-25 21:11:40 ----

Created an attachment
Fixes padding of short callnumbers and Bib-1 attribute for sorting 

With this patch C4/ClassSortRoutine/Dewey.pm gives the following paddings: 

Input      -> Old routine             => Proposed patch      
306        -> 306                     => 306_000000000000000 
306. Les   -> 306__Les                => 306_000000000000000__Les
306.46     -> 306_460000000000000     => 306_460000000000000 
306 Les    -> 306_Les                 => 306_000000000000000_Les
306.0 Les  -> 306_000000000000000_Les => 306_000000000000000_Les
306.4 Les  -> 306_400000000000000_Les => 306_400000000000000_Les
306.40 Les -> 306_400000000000000_Les => 306_400000000000000_Les
306.46 Les -> 306_460000000000000_Les => 306_460000000000000_Les

Most important is that "306 Les" is now turned into 306_000000000000000_Les. This did what I wanted at the databaselevel, after I saved the records again: 

mysql> select cn_sort, cn_source from items;
+--------------------------+-----------+
| cn_sort                  | cn_source |
+--------------------------+-----------+
| 346_000000000000000_LES  | ddc       | 
| 346_040000000000000_LES  | ddc       | 
+--------------------------+-----------+

But it did not have any impact on the actual sorting in the OPAC...

I found that in C4/Search.pm call_number_asc and call_number_desc are set up to sort by 1=20, but this is mapped to Local-classification in ccl.properties, which is mapped to 952$o in record.abs. This patch changes these sorts to use 1=8007, which is mapped to cn-sort and 952$6 (the MARC-field that is actually affected by the padding in C4/ClassSortRoutine/Dewey.pm).

This *seems* to have solved the problem, but I have only tested it with a limited number of records, so if anyone would like to test/verify the results that would be most welcome. 



---- Additional Comments From magnus@enger.priv.no 2010-02-25 21:13:48 ----

Created an attachment
Small script used to test the proposed changes to C4/ClassSortRoutine/Dewey.pm





--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:25 UTC  ---

This bug was previously known as _bug_ 4265 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265
Imported an attachment (id=1964)
Imported an attachment (id=1965)
Imported an attachment (id=1966)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member jwagner@ptfs.com does not have an account here
The original submitter of attachment 1964 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1965 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1966 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Chris Cormack 2011-03-29 08:59:28 UTC
Pushed, please test
Comment 2 MJ Ray (software.coop) 2011-04-02 11:41:28 UTC
This bug is mentioned in:
Bug 4265: Fix padding of short	callnumbers and Bib-1 attribute for sorting http://lists.koha-community.org/pipermail/koha-patches/2011-March/014274.html
Bug 4265: Fix padding of short callnumbers and Bib-1 attribute for sorting http://lists.koha-community.org/pipermail/koha-patches/2011-March/014275.html
Bug 4265: Fix padding of short	callnumbers and Bib-1 attribute for sorting http://lists.koha-community.org/pipermail/koha-patches/2011-March/014276.html