https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #33 from David Cook <dcook@prosentient.com.au> --- (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 thought cn_sort was updated when an item is edited/changed or the touch script is run, but it looks like that might not be the case. Looking at Koha/Item.pm, it looks like cn_sort is only generated for new items OR if you're modifying an item and specifically changing the itemcallnumber or cn_source. This makes some sense because it reduces the likelihood of re-computing the same values, but... it does actually mean it's difficult to re-generate cn_sort. I've had some libraries with cn_sort issues, and I've had to do custom scripts today to re-generate the cn_sort. -- You are receiving this mail because: You are watching all bug changes.