https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18458
--- Comment #6 from Janusz Kaczmarek <[email protected]> --- (In reply to Marcel de Rooy from comment #5) > Janusz, > Thx again for this patch. > I am not so sure though if your code really makes sub merge easier (it is > hard enough already). > Couldnt we do the following in order to keep the order intact: > > Copy all fields in original order including $9. > Overwrite the authority controlled fields. If $overwrite, delete a subfield > that is not controlled (only skip $9). [A hypothetical question: what about > repeated subfields?] > Update $9 finally. > > Another thing: > - append_fields_ordered( $marcrecord, $field_to ); > + $marcrecord->insert_fields_ordered($field_to); > This is a regression. Look at the comments in append_fields_ordered. You > change the order of fields here. > > Finally, we need some tests to support your changes. Have a look at > t/db_dependent/Authority/Merge.t :) Hi Marcel, Thank you for your comments. From the bottom up: You are right--but I have never done it (the t/ story) :( append_fields_ordered -- you are right, I mixed it with append_fields -- and this is what I wouldn't like here, hence the correction that turns out to be regression. Hmmm, and what does it mean indeed "controlled" at all? Because even with the current approach we do not "clear" obviously controlled subfields that had been introduced by mistake by a cataloger. (E.g. if there is $a-$d in personal name authority record, but a cataloger by mistake put additional $c by hand, $c will not disappear after a "refreshing" merge; it disappears only if it was $a-$c first in authority and then becomes $a-$d). But anyway, it is definitely better now than it was before your corrections. But--wouldn't we need something like: C4/Heading/MARC21.pm (which is used for linking) to clearly state what is controlled?--I now, it is hardcoded, but MARC itself is hardcoded too, i.e. title is in 245 $a (resp. 200 $a) etc. Again, I feel like my proposal is more error-proof. I mean: controlled subfields form always a coherent block (do they?). So, if a cataloger puts, by mistake, an uncontrolled subfield between controlled subfields (which is not very rare in standard Koha editor)--it will go to the end after my merge (which was most probably his/hers intention). Only if he/she puts an uncontrolled introductory subfield at the beginning, it will remain there. And, if $overwrite, it is no sense at all to copy the original field--it seems to me it even more complicated than my approach, that I like ;) And even worse: with your proposal there is no simple way to cope with potentially repeated subdields (e.g. $x) that would be subject to changed. And as to $9--yes, we like to have it at the very end (since it it totally non standard and since it blemish the Labeled MARC view! :) So, to sum up: I would willingly return to append_fields_ordered, but if I could ask for suggestions on how to prepare t/, would be great. I would appreciate your comments. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
