Bug 27509 - cn_sort value is lost when editing an item without changing cn_source or itemcallnumber
Summary: cn_sort value is lost when editing an item without changing cn_source or item...
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
: 27843 (view as bug list)
Depends on: 23463
Blocks:
  Show dependency treegraph
 
Reported: 2021-01-21 14:08 UTC by Andrew Fuerste-Henry
Modified: 2021-04-16 14:19 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:
21.05.00,20.11.02,20.05.08


Attachments
Bug 27509: Prevent cn_sort value to be lost when editing items (4.02 KB, patch)
2021-01-21 16:24 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 27509: Prevent cn_sort value to be lost when editing items (4.09 KB, patch)
2021-01-21 16:32 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 27509: Prevent cn_sort value to be lost when editing items (4.14 KB, patch)
2021-01-21 16:39 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 27509: Prevent cn_sort value to be lost when editing items (4.08 KB, patch)
2021-01-21 16:42 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 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. ***