Summary: | cn_sort value is lost when editing an item without changing cn_source or itemcallnumber | ||
---|---|---|---|
Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrew> |
Component: | Cataloging | Assignee: | 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
|
|
Circulation function: | |||
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
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. |