To recreate: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is now null - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is back!
Created attachment 115575 [details] [review] Bug 27509: Prevent cn_sort value to be lost when editing items This is a bit dirty, cn_sort is not passed from the UI but built in Koha::Item->store depending on the values of itemcallnumber and cn_source. It must be updated only if one of those 2 attributes are modified. The problem is that, as it's not passed, $item->{cn_sort} does not exist, and set_or_blank will set it to undef. The trick here is to backup the value before set_or_blank and set it back to the item object. Another solution would be to force the processing of cn_sort each time we call Koha::Item->store. I don't think that's a good idea. Test plan: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is not modified - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is modified as expected
Created attachment 115577 [details] [review] Bug 27509: Prevent cn_sort value to be lost when editing items This is a bit dirty, cn_sort is not passed from the UI but built in Koha::Item->store depending on the values of itemcallnumber and cn_source. It must be updated only if one of those 2 attributes are modified. The problem is that, as it's not passed, $item->{cn_sort} does not exist, and set_or_blank will set it to undef. The trick here is to backup the value before set_or_blank and set it back to the item object. Another solution would be to force the processing of cn_sort each time we call Koha::Item->store. I don't think that's a good idea. Test plan: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is not modified - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is modified as expected Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 115579 [details] [review] Bug 27509: Prevent cn_sort value to be lost when editing items This is a bit dirty, cn_sort is not passed from the UI but built in Koha::Item->store depending on the values of itemcallnumber and cn_source. It must be updated only if one of those 2 attributes are modified. The problem is that, as it's not passed, $item->{cn_sort} does not exist, and set_or_blank will set it to undef. The trick here is to backup the value before set_or_blank and set it back to the item object. Another solution would be to force the processing of cn_sort each time we call Koha::Item->store. I don't think that's a good idea. Test plan: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is not modified - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is modified as expected Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 115580 [details] [review] Bug 27509: Prevent cn_sort value to be lost when editing items This is a bit dirty, cn_sort is not passed from the UI but built in Koha::Item->store depending on the values of itemcallnumber and cn_source. It must be updated only if one of those 2 attributes are modified. The problem is that, as it's not passed, $item->{cn_sort} does not exist, and set_or_blank will set it to undef. The trick here is to backup the value before set_or_blank and set it back to the item object. Another solution would be to force the processing of cn_sort each time we call Koha::Item->store. I don't think that's a good idea. Test plan: - Create a new item with a cn_source value and an itemcallnumber value - write a quick report to see the cn_sort value: SELECT cn_sort FROM items WHERE itemnumber=your itemnumber, see your item has a cn_sort value - edit your item and save it without changing either the cn_source of the itemcallnumber - run your report again, cn_sort is not modified - edit your item, changing either the cn_source or itemcallnumber - run report again, cn_sort is modified as expected Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Pushed to master for 21.05, thanks to everybody involved!
Pushed to 20.11.x for 20.11.02
Pushed to 20.05.x for 20.05.08
Missing dependencies for 19.11.x, it shouldn't be affected, no backport.
*** Bug 27843 has been marked as a duplicate of this bug. ***