Bug 27509

Summary: cn_sort value is lost when editing an item without changing cn_source or itemcallnumber
Product: Koha Reporter: Andrew Fuerste-Henry <andrewfh>
Component: CatalogingAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: critical    
Priority: P5 - low CC: caroline.cyr-la-rose, fridolin.somers, jonathan.druart, m.de.rooy, marjorie.barry-vila, mkstephens, nick, pgm0203, victor
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27843
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
21.05.00,20.11.02,20.05.08
Bug Depends on: 23463    
Bug Blocks:    
Attachments: Bug 27509: Prevent cn_sort value to be lost when editing items
Bug 27509: Prevent cn_sort value to be lost when editing items
Bug 27509: Prevent cn_sort value to be lost when editing items
Bug 27509: Prevent cn_sort value to be lost when editing items

Description Andrew Fuerste-Henry 2021-01-21 14:08:39 UTC
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!
Comment 1 Jonathan Druart 2021-01-21 16:24:22 UTC Comment hidden (obsolete)
Comment 2 Andrew Fuerste-Henry 2021-01-21 16:32:14 UTC Comment hidden (obsolete)
Comment 3 Nick Clemens (kidclamp) 2021-01-21 16:39:58 UTC
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>
Comment 4 Owen Leonard 2021-01-21 16:42:06 UTC Comment hidden (obsolete)
Comment 5 Jonathan Druart 2021-01-22 13:55:06 UTC
Pushed to master for 21.05, thanks to everybody involved!
Comment 6 Fridolin Somers 2021-01-22 14:19:43 UTC
Pushed to 20.11.x for 20.11.02
Comment 7 Andrew Fuerste-Henry 2021-01-22 14:48:40 UTC
Pushed to 20.05.x for 20.05.08
Comment 8 Victor Grousset/tuxayo 2021-01-22 20:55:59 UTC
Missing dependencies for 19.11.x, it shouldn't be affected, no backport.
Comment 9 Jonathan Druart 2021-03-11 13:16:13 UTC
*** Bug 27843 has been marked as a duplicate of this bug. ***