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)
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.
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!
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.)
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 )
(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?
*** Bug 27429 has been marked as a duplicate of this bug. ***
+1
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.
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
Created attachment 174793 [details] [review] Bug 14907: Unit tests
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)
Created attachment 174861 [details] [review] Bug 14907: Unit tests Signed-off-by: Gretchen Maxeiner <maxeinerGL@gcc.edu>
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>