Wishlist: Tracking bib record merges

Bug #1744996 reported by Bill Erickson
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

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.


Revision history for this message
Bill Erickson (berick) wrote :

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.

Revision history for this message
Jason Boyer (jboyer) wrote :

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.

Revision history for this message
Elaine Hardy (ehardy) wrote :

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.

Revision history for this message
Bill Erickson (berick) wrote :

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.

Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

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.

Revision history for this message
Bill Erickson (berick) wrote :

Here's a working branch:


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.

Revision history for this message
Bill Erickson (berick) wrote :

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.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1-beta
Revision history for this message
April Durrence (april-durrence) wrote :

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. ;)

Revision history for this message
Bill Erickson (berick) wrote :

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.

Revision history for this message
Remington Steed (rjs7) wrote :
tags: added: signedoff
Revision history for this message
Dan Wells (dbw2) wrote :

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

Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
status: New → Fix Committed
assignee: Dan Wells (dbw2) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers