https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #33 from David Cook <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
