Subfield order in bib. record changes when editing authority

This has been the normal behaviour since the summer of 2010 when it
was initially implemented. As the content of the $0 subfield is not
expected to be read by any humans other than to cataloguers, we didn't
think this presented a problem.

Tools that display the contents of a 650, for example, should strip
the $0 subfield out no matter where it appears in the field, right?

I've now confirmed that this is a problem for subfields that are not part of the list of controlled subfields. For example, in the current trunk mapping of controlled fields/subfields, 600$c is not controlled. Here's what happens when you control the 600 field containing a $c, then modify the linked authority record:

Original, uncontrolled field:

=600 00 $aWilliam,$cPrince, grandson of Elizabeth II, Queen of Great Britain,$d1982-$xRelations with women.

Field after it has been controlled and the $0 has been added:

=600 00 $aWilliam,$cPrince, grandson of Elizabeth II, Queen of Great Britain,$d1982-$xRelations with women.$0(CONS)2

Field after the linked authority record has been modified:

=600 00$cPrince, grandson of Elizabeth II, Queen of Great Britain,$0(CONS)2$aWilliam,$d1982-$xRelations with women.

As the order of subfields other than $0 does matter for display, even for uncontrolled subfields, this is a problem.

Reported against 2.0, where it will NOT be fixed.

I am setting to incomplete pending confirmation that it is still an issue that needs fixing in 2.1+.

I saw this bug occur after we would merge two duplicate authority records that had bibs linked to at least one of the auth records (or both of them). This was a couple of years ago, at every EG conference since 2012 someone mentions that bug to me. Good to know that there was a an existing LP bug for it.

I can confirm that this bug still happens exactly as diagnosed by Dan S. in comment #2. This was tested on a relatively recent version of master.

Given that this has not been targeted at any milestones, nor is anyone working on it AFAIK, I am setting importance to Medium.

If I'm reading the code right, the problem appears to be that the DB function vandelay.replace_field() performs the replacement action in 2 steps, one to remove the controlled subfields, followed by another to add them back with the new values. Since the add action is decoupled from the remove action, the controlled subfields are simply added to the end of the marc field.

Presumably vandelay.replace_field() will need to morph into something a little smarter, like vandelay.strip_field() or vandelay.add_field(), which parse the record in search of data to affect.

I think it might also be possible to extend vandelay.strip_field() and teach it to apply a replacement value to each would-be-deleted subfield instead of deleting them.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp712490-vandelay-replace-field-retain-order

This branch replaces vandelay.replace_field() function with a PGPERL handler, very similar to vandelay.strip_field() and vandelay.add_field(). In short, when replacing subfield-level values, it performs a merge instead of a delete+add.

The code iterates each affected field, leaving uncontrolled subfields alone, replacing values for matching controlled subfields, splicing in new controlled subfields (i.e. those that only existing on the source record), and deleting controlled subfields that only exist on the target field.

The final result is consistent with the existing vandelay.add_field() with respect to which fields are present. The only difference is the field order.

I have confirmed Dan's example from comment #2 now retains the field order (assuming 600$c is uncontrolled).

Includes PGTAP test.

To test:

[1] Link a an authority record to a bib field by adding a $0 as the final subfield.
[2] Modify the authority record
[3] Confirm the modifications propagated to the affected bib field leaving the $0 as the last field.

Followed process outlined in #8, using same example/subfields from #2.

Modifying authority record now leaves $0 as final subfield. Authority displays correctly in OPAC view.

I agree with Meg. With Bill's fix, editing the authority record doesn't cause the uncontrolled subfields to get out of order. Thanks, Bill and Meg! It will be very nice to have this fixed.

I have tested this code and consent to signing off on it with my name, Jane Sandberg, and my email address, <email address hidden>.

Pushed to master, rel_3_2, and rel_3_1.

Thanks, everyone!