Bug 17913: Fix the new field tag in merge when changing type
authorMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
Mon, 16 Jan 2017 13:54:37 +0000 (14:54 +0100)
committerKyle M Hall <kyle@bywatersolutions.com>
Fri, 20 Jan 2017 13:55:11 +0000 (13:55 +0000)
commit8cde85451e3bae584ed1838efcaa4085cb656dfe
treeb9c462a9d3faf30caa946717c1c2f0b4cdd9c0a6
parent9290e10abee67fea6619ae6a1564fc96777274b4
Bug 17913: Fix the new field tag in merge when changing type

Originally aimed for 9988, adjusted for this report.

Old behavior was: pick the first tag. This is definitely wrong.
If you (would) merge 610 to 611, you don't want to get a 111.

This patch resolves the problem by determining the new tag in a small
helper routine _merge_newtag, and corrects the position of the new field
in the MARC record with append_fields_ordered. Too bad that MARC::Record
does not have such a function; it looks like insert_fields_ordered, but
it is different in case of multiple fields with the same tag.

Note: These two small helper functions are not tested separately, since they
should not be called outside of merge. They are implicitly tested by the
adjusted tests in Merge.t.

Note: In adding tests for this fix, I chose to simplify compare_field_count
(no need for the pass parameter), and replace the pass parameter of sub
compare_field_order by an exclude parameter, a hash of fields to exclude in
counting fields.

Test plan:
Run t/db_dependent/Authorities/Merge.t

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4/AuthoritiesMarc.pm
t/db_dependent/Authorities/Merge.t