[Koha-bugs] [Bug 18458] Merging authority record incorrectly orders subfields

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Nov 27 18:20:08 CET 2017


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18458

--- Comment #6 from Janusz Kaczmarek <januszop at gmail.com> ---
(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.


More information about the Koha-bugs mailing list