---- 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.