|Summary:||Inventory lists incorrectly sorted|
|Product:||Koha||Reporter:||David Cook <dcook>|
|Component:||Tools||Assignee:||Bugs List <koha-bugs>|
|Status:||CLOSED WONTFIX||QA Contact:||Testopia <testopia>|
|Priority:||P5 - low||CC:||black23, katrin.fischer|
|Change sponsored?:||---||Patch complexity:||---|
|Documentation contact:||Documentation submission:|
|Text to go in the release notes:||Version(s) released in:|
Description David Cook 2018-09-28 06:29:31 UTC
In the real world, I've found the cn_sort field does not always have correct values, and the same itemcallnumber field may have different cn_sort values. My theory is that the method for generating cn_sort changed at some point, and that has created inconsistencies in the creation of cn_sort value, especially in Koha databases that have existed for a long period of time. -- I received reports that the lists generated by /cgi-bin/koha/tools/inventory.pl and shown on screen weren't sorted by call number. That led me to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19021 and that seemed to solve the problem as it resorted the data table by the call number. However, when using the "Export to CSV file" option, the data was still not sorted correctly, and thus was incompatible with the data table shown on screen, which defeats the purpose of doing an inventory without a scanned barcode file. -- This can be solved by running touch_all_items.pl. However, this is not a systematic solution. Perhaps we should do a database revision that runs ModItem for all items. This seems problematic for databases with large numbers of items, but it seems a good idea to provide a systematic solution instead of requiring people to run touch_all_items.pl if they notice the problem.
Comment 1 Katrin Fischer 2018-09-28 06:32:44 UTC
Maybe the name of this bug should then be "Add a script to update cn_sort"? This is a data problem and not a problem of the sorting itself. touch_items is rather costly/time consuming, we recently fixed it using a little script creating SQL statements for the updates.
Comment 2 David Cook 2018-09-28 06:46:54 UTC
(In reply to Katrin Fischer from comment #1) > Maybe the name of this bug should then be "Add a script to update cn_sort"? > This is a data problem and not a problem of the sorting itself. > Yeah that could be a good idea. I guess I'm not sure at this point why the cn_sort values became inconsistent, so looking for ideas. Although based on what you said on IRC, I'm thinking maybe it's an issue with an external dependency? If it is an external dependency, maybe I can trace in what version it changed and then base the update around that? > touch_items is rather costly/time consuming, we recently fixed it using a > little script creating SQL statements for the updates. You mean you created a little script for updating cn_sort? I hadn't thought of doing the update directly like that. That's a good idea. I don't suppose we use the cn_sort value in any indexes?
Comment 3 Katrin Fischer 2018-09-30 12:14:03 UTC
I think we have foregone the Zebra updates - but we will update them soon anyway which will include a full reindex. Another thing to check: Is cn_source set correctly in all items? It's easy to have some bad configuration there.
Comment 4 David Cook 2018-10-02 00:03:48 UTC
(In reply to Katrin Fischer from comment #3) > Another thing to check: Is cn_source set correctly in all items? It's easy > to have some bad configuration there. I was thinking that as well but in my case the items seemed to all have cn_source set correctly.
Comment 5 Katrin Fischer 2019-02-02 14:39:01 UTC
I feel if we agree this is a data issue, the bug could probably be closed? I filed bug 22263 for adding a maintenance script.