Bug 27509: Prevent cn_sort value to be lost when editing items
authorJonathan Druart <jonathan.druart@bugs.koha-community.org>
Thu, 21 Jan 2021 16:21:15 +0000 (17:21 +0100)
committerJonathan Druart <jonathan.druart@bugs.koha-community.org>
Fri, 22 Jan 2021 12:46:38 +0000 (13:46 +0100)
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>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4/Items.pm
t/db_dependent/Items.t

index 430ca8e..527e11c 100644 (file)
@@ -318,10 +318,15 @@ sub ModItemFromMarc {
     }
 
     $item->{cn_source} = delete $item->{'items.cn_source'}; # Because of C4::Biblio::_disambiguate
-    $item->{cn_sort}   = delete $item->{'items.cn_sort'};   # Because of C4::Biblio::_disambiguate
+    delete $item->{'items.cn_sort'};   # Because of C4::Biblio::_disambiguate
     $item->{itemnumber} = $itemnumber;
     $item->{biblionumber} = $biblionumber;
+
+    my $existing_cn_sort = $item_object->cn_sort; # set_or_blank will reset cn_sort to undef as we are not passing it
+                                                  # We rely on Koha::Item->store to modify it if itemcallnumber or cn_source is modified
     $item_object = $item_object->set_or_blank($item);
+    $item_object->cn_sort($existing_cn_sort); # Resetting to the existing value
+
     my $unlinked_item_subfields = _get_unlinked_item_subfields( $localitemmarc, $frameworkcode );
     $item_object->more_subfields_xml(_get_unlinked_subfields_xml($unlinked_item_subfields));
     $item_object->store({ skip_record_index => $params->{skip_record_index} });
index 4f94041..a5e4a52 100755 (executable)
@@ -981,7 +981,7 @@ subtest 'Split subfields in Item2Marc (Bug 21774)' => sub {
 };
 
 subtest 'ModItemFromMarc' => sub {
-    plan tests => 4;
+    plan tests => 5;
     $schema->storage->txn_begin;
 
     my $builder = t::lib::TestBuilder->new;
@@ -1021,5 +1021,21 @@ subtest 'ModItemFromMarc' => sub {
     is( $updated_item->{new_status}, "this is something", "Non mapped field has not been reset" );
     is( Koha::Items->find($itemnumber)->new_status, "this is something" );
 
+    subtest 'cn_sort' => sub {
+        plan tests => 3;
+
+        my $item = $builder->build_sample_item;
+        $item->set({ cn_source => 'ddc', itemcallnumber => 'xxx' })->store;
+        is( $item->cn_sort, 'XXX', 'init values set are expected' );
+
+        my $marc = C4::Items::Item2Marc( $item->get_from_storage->unblessed, $item->biblionumber );
+        ModItemFromMarc( $marc, $item->biblionumber, $item->itemnumber );
+        is( $item->get_from_storage->cn_sort, 'XXX', 'cn_sort has not been updated' );
+
+        $marc = C4::Items::Item2Marc( { %{$item->unblessed}, itemcallnumber => 'yyy' }, $item->biblionumber );
+        ModItemFromMarc( $marc, $item->biblionumber, $item->itemnumber );
+        is( $item->get_from_storage->cn_sort, 'YYY', 'cn_sort has been updated' );
+    };
+
     $schema->storage->txn_rollback;
 };