https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36515
--- Comment #18 from Michał <[email protected]> --- [sorry for mail spam in advance] By reading the code, it appears that the reason the other way around doesn't work is that extracting the old value works both from subfield and control field, but the function that sets new value - _update_subfield - doesn't seem to handle setting control field value. The code path that we use (but regrettably both would have to be fixed) calls this: my $field = MARC::Field->new( $fieldName, '', '', "$subfieldName" => $values[$i++] ); To fix this, it should probably check if $subfieldName is `( !defined $subfieldName or $subfieldName eq '' )` and then if the $fieldName is `< "010"`, in such case it should instead run: MARC::Field->new( $fieldName, $values[$i++] ) In fact, this is almost exactly what func `add_field` in the same file does: if ( $fieldName > 10 ) { foreach my $value ( @values ) { my $field = MARC::Field->new( $fieldName, '', '', "$subfieldName" => $value ); $record->insert_fields_ordered( $field ); } } else { foreach my $value ( @values ) { my $field = MARC::Field->new( $fieldName, $value ); $record->insert_fields_ordered( $field ); } Turns out `_update_subfield` has a sister `_update_field`, which is why they don't do such a check. So `_copy_move_subfield` has to be changed from: _update_subfield({ record => $record, field => $toFieldName, subfield => $toSubfieldName, values => \@values, dont_erase => $dont_erase }); to have a check that calls `_update_field` instead if it's control. Unfortunately I don't have ktd setup handy next to me right now, so I can't file a fix for the time being. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
