Bug 14907 - Item search: call numbers in Item search results are ordered alphabetically
Summary: Item search: call numbers in Item search results are ordered alphabetically
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Nick Clemens (kidclamp)
QA Contact: Marcel de Rooy
URL:
Keywords:
: 27429 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-28 09:33 UTC by Theodoros Theodoropoulos
Modified: 2025-01-26 22:28 UTC (History)
17 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This fixes item search results when ordering the results by the call number. They are now correctly ordered using cn_sort, instead of a basic "alphabetical" order (cn_sort uses the appropriate sorting rules for the classification scheme).
Version(s) released in:
25.05.00
Circulation function:


Attachments
Bug 14907: Unit tests (2.06 KB, patch)
2024-11-19 15:42 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 14907: Sort item search by cn_sort when sorting by callnumber (1.28 KB, patch)
2024-11-19 15:42 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 14907: Unit tests (2.11 KB, patch)
2024-11-20 21:12 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 14907: Sort item search by cn_sort when sorting by callnumber (1.33 KB, patch)
2024-11-20 21:12 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 14907: Sort item search by cn_sort when sorting by callnumber (1.39 KB, patch)
2024-11-26 16:18 UTC, PTFS Europe Sandboxes
Details | Diff | Splinter Review
Bug 14907: Unit tests (2.21 KB, patch)
2025-01-10 08:04 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 14907: Sort item search by cn_sort when sorting by callnumber (1.48 KB, patch)
2025-01-10 08:04 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Theodoros Theodoropoulos 2015-09-28 09:33:38 UTC
Call Numbers in Item search results seem to be sorted ALPHABETICALLY, so currently it is displayed:
QA76.76
QA76.760
QA76.77

where the results should be shown in the following order:
QA76.76
QA76.77
QA76.760

The callnumber ordering is a complex issue [it should be partly alphabetical partly numerical] but once done, it would be very useful for sorting and could be applied to several places in Koha (browsing shelves, inventory, etc)
Comment 1 Katrin Fischer 2015-09-29 21:48:30 UTC
There is actually a "sorting form" of the callnumber in cn_sort that is created by using the callnumber and the classification source. It might help to have this added to the table as a hidden field used for sorting, while displaying the callnumber.
Comment 2 Owen Leonard 2018-05-24 17:06:35 UTC
The item search table is rendered server-side, so all sorting happens server-side. This eliminates some of our standard sorting methods, like embedding a sortable string in a title tag.

Renaming the column "cn_sort" has the right effect for the purposes of sorting: The column name "cn_sort" is passed to the query and the rows are sorted correctly by call number.

Unfortunately this breaks the column filter: "cn_sort" is an ambiguous column name for the purposes of the query because of biblioitems.cn_sort. I'm not sure if there is a good way to handle this besides adding some conditional code specific to these columns.

Suggestions welcome!
Comment 3 Joelle Hannert 2020-08-07 15:22:42 UTC
We are using the cn_sort workaround for running item reports to sort by call number, but we've been unable to find a solution that will work within the Item Search. It's too bad, because Item Search could be a really useful tool for title-by-title type work (like weeding or shelf-reading.)
Comment 4 Heather 2021-12-02 20:21:59 UTC
We're on 21.05, and the item search is the *only* place where Library of Congress call numbers are sorting correctly.  I'm a little confused about your example, too--are the call numbers in your example Library of Congress call numbers, or call numbers in a different classification system?  Library of Congress call numbers' initial alpha-numeric sequence are decimals after the period, so there wouldn't be a call number, "QA76.760" because this is the same as "QA76.76"--Library of Congress call numbers never end with a zero after the decimal.  If it were a call number used locally, this sorting is correct:

> Call Numbers in Item search results seem to be sorted ALPHABETICALLY, so
> currently it is displayed:
> QA76.76
> QA76.760
> QA76.77

The filing rule for this, if I remember correctly, is covered in the Library of Congress Filing Rules, illustrated by this example, where the absence of a character comes before the presence of a character--that is, "nothing comes before something:"
A is for anatomy
A4D desert speed run

So this isn't correct, for Library of Congress call numbers:
> where the results should be shown in the following order:
> QA76.76
> QA76.77
> QA76.760

Because "point seven six zero" is less than "point seven seven."  But if these aren't Library of Congress call numbers, then the sorting would be different?  The LC Filing Rules say, "Arrange numerals after a decimal point digit by
digit, one place at a time."  So, also, ".760" can't come after ".77," if you're arranging digit-by-digit, one place at a time.  (This is in section 14 of https://www.loc.gov/catdir/cpso/G100.pdf )
Comment 5 Katrin Fischer 2022-01-09 00:21:10 UTC
(In reply to Owen Leonard from comment #2)
> The item search table is rendered server-side, so all sorting happens
> server-side. This eliminates some of our standard sorting methods, like
> embedding a sortable string in a title tag.
> 
> Renaming the column "cn_sort" has the right effect for the purposes of
> sorting: The column name "cn_sort" is passed to the query and the rows are
> sorted correctly by call number.
> 
> Unfortunately this breaks the column filter: "cn_sort" is an ambiguous
> column name for the purposes of the query because of biblioitems.cn_sort.
> I'm not sure if there is a good way to handle this besides adding some
> conditional code specific to these columns.
> 
> Suggestions welcome!

Hi Owen,

does that mean we should expect similar issues for date sorting for server side rendered tables? Or is it something specific to how this table was implemented?
Comment 6 Owen Leonard 2022-03-16 11:55:59 UTC
*** Bug 27429 has been marked as a duplicate of this bug. ***
Comment 7 Laura Escamilla 2024-06-21 18:59:57 UTC
+1
Comment 8 Gretchen Maxeiner 2024-07-01 12:55:06 UTC
We would very much like to see improvement to call number sorting for Library of Congress classification in Item Search. We are new to Koha and working in 24.05, and the sort is alphabetical instead of based on LC filing order. Examples are:

D101.2.A8 1951
D1015.B4 1965
D102.D3 1930

and

E129.D7 B47 2021
E13.M3 1968
E143.S76 2013

It's a little unclear if this was actually an issue in past releases from the comments above, but I wanted to document that the sort is definitely incorrect in the current release.
Comment 9 Heather 2024-07-01 15:37:25 UTC
Hi, Gretchen!

We are on 23.05.11, and our call numbers are sorting correctly (except for some of the very different geographic call numbers with colons in them), but we do not have the period/full stop in front of the initial cutter in the item records.  We do have the call numbers formatted correctly in the bib record 050 and 090 fields, but we strip that period/full stop from the item record call number.  (Our catalog is at http://keys.bywatersolutions.com/ )

There is some sorting weirdness with geographic call numbers that have colons in them, but that's not part of this bug!:)

So we're not able to replicate the problem initially reported in this bug, even with the initial alphanumeric sequence of the call number. (And in the initial report, "QA76.760" wouldn't be valid anyway--the initial alphanumeric sequence's decimal portion can never end with a zero.)

Cheerio!
h2
Comment 10 Nick Clemens (kidclamp) 2024-11-19 15:42:09 UTC
Created attachment 174793 [details] [review]
Bug 14907: Unit tests
Comment 11 Nick Clemens (kidclamp) 2024-11-19 15:42:11 UTC
Created attachment 174794 [details] [review]
Bug 14907: Sort item search by cn_sort when sorting by callnumber

This patch simply intercepts a call to sort by callnumber and changes it to cn_sort

To test:
1 - Add three items:
    barcode TEST1 callnumnber D1015.B4 1965
    barcode TEST2 callnumnber D102.D3 1930
    barcode TEST3 callnumnber D101.2.A8 1951
2 - Go to item search
3 - barcode is 'TEST%'
4 - Sort the results by callnumber
5 - order is TEST3,TEST1,TEST2 (or reversed depending on sort direction)
6 - Apply patch, restart_all
7 - sort again
8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)
Comment 12 Andrew Fuerste-Henry 2024-11-20 21:12:45 UTC
Created attachment 174861 [details] [review]
Bug 14907: Unit tests

Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>
Comment 13 Andrew Fuerste-Henry 2024-11-20 21:12:48 UTC
Created attachment 174862 [details] [review]
Bug 14907: Sort item search by cn_sort when sorting by callnumber

This patch simply intercepts a call to sort by callnumber and changes it to cn_sort

To test:
1 - Add three items:
    barcode TEST1 callnumnber D1015.B4 1965
    barcode TEST2 callnumnber D102.D3 1930
    barcode TEST3 callnumnber D101.2.A8 1951
2 - Go to item search
3 - barcode is 'TEST%'
4 - Sort the results by callnumber
5 - order is TEST3,TEST1,TEST2 (or reversed depending on sort direction)
6 - Apply patch, restart_all
7 - sort again
8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)

Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>
Comment 14 PTFS Europe Sandboxes 2024-11-26 16:18:41 UTC
Created attachment 174990 [details] [review]
Bug 14907: Sort item search by cn_sort when sorting by callnumber

This patch simply intercepts a call to sort by callnumber and changes it to cn_sort

To test:
1 - Add three items:
    barcode TEST1 callnumnber D1015.B4 1965
    barcode TEST2 callnumnber D102.D3 1930
    barcode TEST3 callnumnber D101.2.A8 1951
2 - Go to item search
3 - barcode is 'TEST%'
4 - Sort the results by callnumber
5 - order is TEST3,TEST1,TEST2 (or reversed depending on sort direction)
6 - Apply patch, restart_all
7 - sort again
8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)

Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>
Signed-off-by: Heather Hernandez <flyingendpaper@gmail.com>
Comment 15 Marcel de Rooy 2024-12-13 09:49:15 UTC
(In reply to PTFS Europe Sandboxes from comment #14)
>     barcode TEST1 callnumnber D1015.B4 1965
>     barcode TEST2 callnumnber D102.D3 1930
>     barcode TEST3 callnumnber D101.2.A8 1951
> 8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)
> 
> Signed-off-by: Heather Hernandez <flyingendpaper@gmail.com>

While reading comment4 of Heather, I am not sure what the LCC order now should be. IIUC the order should be 1-11-2. But this test marks 101-102-1015 as correct while I expected 101-1015-102 ?

Please clarify.

PS The general scheme sorts also like 1-11-2 for our callnumbers like 10 A 1, 100 A 2 or 1000 A 3. Which is a pain since we started.
Comment 16 Katrin Fischer 2024-12-13 12:54:31 UTC
But isn't this more a question of how the cn_sort is generated instead of making sure it's using cn_sort for sorting?
Comment 17 Marcel de Rooy 2024-12-13 14:19:03 UTC
(In reply to Katrin Fischer from comment #16)
> But isn't this more a question of how the cn_sort is generated instead of
> making sure it's using cn_sort for sorting?

These are tightly coupled of course.
Comment 18 Katrin Fischer 2024-12-13 14:20:40 UTC
(In reply to Marcel de Rooy from comment #17)
> (In reply to Katrin Fischer from comment #16)
> > But isn't this more a question of how the cn_sort is generated instead of
> > making sure it's using cn_sort for sorting?
> 
> These are tightly coupled of course.

Coupled yes, but this bug doesn't deal with the generation.
Comment 19 Marcel de Rooy 2024-12-16 07:45:32 UTC
(In reply to Katrin Fischer from comment #18)
> (In reply to Marcel de Rooy from comment #17)
> > (In reply to Katrin Fischer from comment #16)
> > > But isn't this more a question of how the cn_sort is generated instead of
> > > making sure it's using cn_sort for sorting?
> > 
> > These are tightly coupled of course.
> 
> Coupled yes, but this bug doesn't deal with the generation.

This bug deals about sorting? So we should use cn_sort and make sure that cn_sort is filled correctly.
Comment 20 Katrin Fischer 2024-12-16 13:58:10 UTC
Sorry, I am not sure I get your point. :(

For me this patch for sorting and the generation of cn_sort are separate. 

cn_sort is generated whenever an item is edited/changed, or the touch script is run, depending on the classification source. Of course there can be bugs in this area too.

For sorting we use cn_sort already in other places like inventory or the callnumber value builder and the field should be used every where we sort on callnumbers. 

For me the goal of this patch is to use the cn_sort data. So I'd probably look at the itmecallnumber, cn_sort and sort by cn_sort with SQL and compare that to what I see in item search.
Comment 21 Marcel de Rooy 2024-12-16 14:02:54 UTC
(In reply to Katrin Fischer from comment #20)
> Sorry, I am not sure I get your point. :(
> 
> For me this patch for sorting and the generation of cn_sort are separate. 
> 
> cn_sort is generated whenever an item is edited/changed, or the touch script
> is run, depending on the classification source. Of course there can be bugs
> in this area too.
> 
> For sorting we use cn_sort already in other places like inventory or the
> callnumber value builder and the field should be used every where we sort on
> callnumbers. 
> 
> For me the goal of this patch is to use the cn_sort data. So I'd probably
> look at the itmecallnumber, cn_sort and sort by cn_sort with SQL and compare
> that to what I see in item search.

I would think that the goal of this report is getting the sort correct. How we do that, is another thing.
Comment 22 Katrin Fischer 2024-12-16 17:48:09 UTC
Using cn_sort is the standard way of doing this, I don't believe there is a better way than using the sorting form of the callnumber.
Comment 23 Heather 2025-01-02 19:17:47 UTC
(In reply to Marcel de Rooy from comment #15)
> (In reply to PTFS Europe Sandboxes from comment #14)
> >     barcode TEST1 callnumnber D1015.B4 1965
> >     barcode TEST2 callnumnber D102.D3 1930
> >     barcode TEST3 callnumnber D101.2.A8 1951
> > 8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)
> > 
> > Signed-off-by: Heather Hernandez <flyingendpaper@gmail.com>
> 
> While reading comment4 of Heather, I am not sure what the LCC order now
> should be. IIUC the order should be 1-11-2. But this test marks 101-102-1015
> as correct while I expected 101-1015-102 ?
> 
> Please clarify.
> 
> PS The general scheme sorts also like 1-11-2 for our callnumbers like 10 A
> 1, 100 A 2 or 1000 A 3. Which is a pain since we started.

The correct order for LC Classification of the above example is:
TEST3, TEST2, TEST1
i.e., D101.2.A8 1951, D102.D3 1930, D1015.B4 1965
i.e.:
D One hundred and one point 2
D One hundred and two
D One thousand and fifteen

One would expect "101-1015-102" if these were decimal numbers in the initial alphanumeric sequence (i.e., "D point one zero one, D point one zero one five, D point one zero two), but they are whole numbers.

So that's why I signed off on the bug--it was sorting these LC Class numbers correctly, as whole numbers.  I.e., an alphanumeric sequence of a letter plus whole numbers.

With Library of Congress Classification, the initial alphanumeric sequence contains whole numbers.  The following alphanumeric sequence(s) contain decimal numbers.  I.e., D1015.B4 1965 is "D One thousand fifteen B four tenths One thousand nine hundred sixty five."  In USian English, that is.:)

Does that help?
--h2
Comment 24 Katrin Fischer 2025-01-03 08:46:12 UTC
(In reply to Heather from comment #23)
> (In reply to Marcel de Rooy from comment #15)
> > (In reply to PTFS Europe Sandboxes from comment #14)
> > >     barcode TEST1 callnumnber D1015.B4 1965
> > >     barcode TEST2 callnumnber D102.D3 1930
> > >     barcode TEST3 callnumnber D101.2.A8 1951
> > > 8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)
> > > 
> > > Signed-off-by: Heather Hernandez <flyingendpaper@gmail.com>
> > 
> > While reading comment4 of Heather, I am not sure what the LCC order now
> > should be. IIUC the order should be 1-11-2. But this test marks 101-102-1015
> > as correct while I expected 101-1015-102 ?
> > 
> > Please clarify.
> > 
> > PS The general scheme sorts also like 1-11-2 for our callnumbers like 10 A
> > 1, 100 A 2 or 1000 A 3. Which is a pain since we started.
> 
> The correct order for LC Classification of the above example is:
> TEST3, TEST2, TEST1
> i.e., D101.2.A8 1951, D102.D3 1930, D1015.B4 1965
> i.e.:
> D One hundred and one point 2
> D One hundred and two
> D One thousand and fifteen
> 
> One would expect "101-1015-102" if these were decimal numbers in the initial
> alphanumeric sequence (i.e., "D point one zero one, D point one zero one
> five, D point one zero two), but they are whole numbers.
> 
> So that's why I signed off on the bug--it was sorting these LC Class numbers
> correctly, as whole numbers.  I.e., an alphanumeric sequence of a letter
> plus whole numbers.
> 
> With Library of Congress Classification, the initial alphanumeric sequence
> contains whole numbers.  The following alphanumeric sequence(s) contain
> decimal numbers.  I.e., D1015.B4 1965 is "D One thousand fifteen B four
> tenths One thousand nine hundred sixty five."  In USian English, that is.:)
> 
> Does that help?
> --h2

Thanks Heather, it does :)
Comment 25 Heather 2025-01-06 21:47:23 UTC
> Thanks Heather, it does :)

Yea!!!
Comment 26 Marcel de Rooy 2025-01-10 07:34:17 UTC
Revisiting this one
Comment 27 Marcel de Rooy 2025-01-10 08:03:46 UTC
Just an observation:
Library-CallNumber-LC-0.23 on CPAN is from 2014 !
Bus factor is 0.
Comment 28 Marcel de Rooy 2025-01-10 08:04:48 UTC
Created attachment 176308 [details] [review]
Bug 14907: Unit tests

Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 29 Marcel de Rooy 2025-01-10 08:04:51 UTC
Created attachment 176309 [details] [review]
Bug 14907: Sort item search by cn_sort when sorting by callnumber

This patch simply intercepts a call to sort by callnumber and changes it to cn_sort

To test:
1 - Add three items:
    barcode TEST1 callnumnber D1015.B4 1965
    barcode TEST2 callnumnber D102.D3 1930
    barcode TEST3 callnumnber D101.2.A8 1951
2 - Go to item search
3 - barcode is 'TEST%'
4 - Sort the results by callnumber
5 - order is TEST3,TEST1,TEST2 (or reversed depending on sort direction)
6 - Apply patch, restart_all
7 - sort again
8 - order is TEST3,TEST2,TEST1 (or reversed depending on sort direction)

Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>
Signed-off-by: Heather Hernandez <flyingendpaper@gmail.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 30 Katrin Fischer 2025-01-10 18:20:35 UTC
Pushed for 25.05!

Well done everyone, thank you!
Comment 31 David Nind 2025-01-26 22:28:19 UTC
I have attempted to add a release note.

Feel free to amend it if I have incorrectly interpreted what this bug fixes.