Wishlist: Tracking bib record merges

[Bill Erickson]

Evergreen 3.0 / Wishlist

It would be nice if admins could tell when a bib record has been merged with/to and when the merge occurred. Similarly, it would be good to know the target record for subordinate record merges. As a practical use case, it helps diagnose cases where hold queues jump in size due to bib merges.

I propose 2 new biblio.record_entry fields, last_merge_date and merged_to. Both source and target records would have values applied for last_merge_date for any merges. And merged_to would be applied to subordinate records (and left NULL for the target record).

At a glance, toward the end of the asset.merge_record_assets() PG func looks like a reasonable place to apply the values.

Thanks to J. Boyer for the merged_to suggestion.

Thoughts?

[Bill Erickson (berick)]

As noted by Dan Scott in IRC, the merged_to value could be used to apply 301 redirects in the catalog, automatically sending users to the merge target of merge-deleted records.

Note that since bib records can be un-deleted, though, it would be possible to create single and muti-step merge loops.

[Jason Boyer (jboyer)]

One way to address that would be to make part of the undelete process clearing the merged_to field. If the record is being re-activated that would indicate to me that the merge should not have been performed.

[Elaine Hardy (ehardy)]

Undeleting the record may not necessarily mean the merge should not have occurred. It may be that the wrong record was used for the items in hand, so they were merged to the correct record (For example, 2nd ed rather than 3rd edition). Then items that match that first record were acquired and the person undeleted rather than reimported. A corner case, but possible.

[Bill Erickson (berick)]

For my part, a merged_to loop is not a problem as long as we're aware it can happen. I would rather retain the details of a merge, regardless of whether it was supposed to happen or not.

[Rogan Hamby (rogan-hamby)]

I do dedupe projects on a regular basis and field these kinds of questions so it's a +1 from me to make this information somewhere it can be exposed via the field mapper. I agree that the merge_to field is fine and the loop should not be a common occurrence and when it does happen easy enough to deal with.

[Bill Erickson (berick)]

Here's a working branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1744996-record-merge-tracking

1. Adds the columns and applies the values on record merge.
2. 2nd commit adds a message to the browser client bib record display indicating when a record was merged with another and links to the target record.

TODO: release notes.

To test:

[1] Add 2 or more records to a record bucket.
[2] Merge said records
[3] Confirm the merge warning appears in the subordinate records.
[4] Confirm the merge_date is also applied to the target record in the DB.

[Bill Erickson (berick)]

Release notes pushed to same branch.

I have no immediate plans to implement OPAC redirection for merged records. If someone implements that now, that would be great, otherwise we can resume via a new LP bug.

[April Durrence (april-durrence)]

Just chiming in to ask whether it would be possible to also track the username of the staff member who merged records? Not critical, but would certainly be useful to be able to run reports in the case of bad merges to identify the need for a little staff re-education. ;)

[Bill Erickson (berick)]

Hi April, we should probably be setting the edit_date and editor on bib records when they are merged into another record. (Arguably, a delete is an edit). With that, you could tell who merged the records by inspecting the editor value on the merged/deleted record.

It may not be the most staff-friendly way to track that, because it requires inspecting the deleted record, but these are fields we already have and can be using better.

[Remington Steed (rjs7)]

Tested, and it worked as advertised. Here's my sign-off branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/lp1744996-record-merge-tracking

[Dan Wells (dbw2)]

This is a great refinement to the merge process. Pushed to master, thanks all!