[Bug 4265] New: Sorting by call number in OPAC is slightly off
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 Summary: Sorting by call number in OPAC is slightly off Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt@gmail.com ReportedBy: magnus@enger.priv.no Estimated Hours: 0.0 Change sponsored?: --- Created an attachment (id=1689) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1689) 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. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 --- Comment #1 from Magnus Enger <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 | +--------------------------+-----------+ -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 Jane Wagner <jwagner@ptfs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwagner@ptfs.com -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 --- Comment #2 from Jane Wagner <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 -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 --- Comment #3 from Magnus Enger <magnus@enger.priv.no> 2010-02-25 21:11:40 --- Created an attachment (id=1696) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1696) 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. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4265 --- Comment #4 from Magnus Enger <magnus@enger.priv.no> 2010-02-25 21:13:48 --- Created an attachment (id=1697) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1697) Small script used to test the proposed changes to C4/ClassSortRoutine/Dewey.pm -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠kohaorg.ec2.liblime.com