How to Handle Duplicate Records

It is a major task for IPDb to make sure that we minimise the number of duplicates found on the IPDb App, as it is confusing to all of us.

Our first line of defence is the duplicate filter that is running while we insert new records. At times, the potential duplicate window will pop up, suggesting that a user may be about to insert a record already in IPDb.

Please read this article on how to handle this situation.

Nevertheless, duplicates may still find their way into IPDb, at times. This article will explain how to handle duplicate records that have slipped through the net.

NOTE:
A word of warning to start with. Some puzzles may SEEM to be duplicates, as they look exactly the same.  However, they may be ever so slightly different and will, therefore, be treated as separate records instead of duplicates in IPDb.

Examples of records which ARE NOT duplicates:

Puzzles from the same brand, but with:

1. Different barcodes:
   This typically happens if the same puzzle is produced in different factories/countries. It may also happen that if a puzzle was previously sold out, and a second edition was produced, years later
2. Different boxes:
   Over time, brands may release versions with minutely different boxes, either front or back. It may be a font change, or slightly different elements on the cover, or they may completely overhaul the box cover for an updated look. If there is the slightest difference between boxes, we consider them NOT to be duplicates
3. Different types of cuts:
   Some brands, such as Eurographics, being one of the main ones, release the same puzzle in different regions with different cuts.  E.g. if it was manufactured in the US/Canada or China, the puzzle could have varying types of grid cuts. However, in Europe, they release their Smart Cut versions, which are a random cut, and while their barcodes and reference numbers may match across regional releases, the type of cut differs greatly. So, in this case, the European Smart Cut version should be given its own, particular record. The box will be different in most cases as well, as the newer one will display the Smart Cut logo.

There are likely to be more instances where puzzles that appear the same, but are not, which makes the problem of duplicates even more frustrating.

When a user (we will refer to them as the 'reporter') finds 2 puzzles which are potential duplicates (we will refer to the 2 puzzles as PuzzleA submitted by UserA and PuzzleB submitted by UserB), they should follow the procedure below:

1. First, navigate to PuzzleA and:
    PC: Click/tap the link icon at the top of the details screen (shown below):

    Mobile device: Click/tap the additional options icon, then select Copy 

    puzzle link to clipboard.

This will copy a link to PuzzleA onto the clipboard (working in the background).

2. Then, navigate to PuzzleB and click the message icon at the bottom of 

    the details screen.

This will display the Message box, which is used within the IPDb App to send messages to other users.

3. In the pop-up window, select the merge tab and paste the link from your clipboard into the edit box. The paste icon is located to the right of the link field; pressing this icon will paste the link previously copied into the link field.

4. By pressing OK, your request to merge PuzzleA and PuzzleB into one common record will be submitted to the Admin Team, as well as the submitters of both puzzles.

Submitter A and Submitter B will need to either accept or reject the merge request, and they should advise Admin if there is a reason why the 2 records should not be merged but remain as separate records.

The Submitters are given 28 days to respond, but if they fail to 'approve/deny' a request, it will be executed automatically (if Admin agrees that the records should be merged).

If a merge proceeds, the most recent puzzle is always merged into the original puzzle. So if PuzzleA was submitted last year, and PuzzleB was submitted this year, PuzzleB will be merged with PuzzleA.

IPDb will check and determine which one is the original submission, so you won't have to worry about figuring that out.

This is important to know, as PuzzleA in this case has priority, meaning that if PuzzleA has an Artist entered as Pablo Picasso, and PuzzleB has an Artist entered as Picasso, then the merged record will have the Artist entered as Pablo Picasso.

However, new information from PuzzleB (which doesn't exist in PuzzleA) will be merged into PuzzleA, so the merged record is a true union of the 2 puzzles.

Whilst waiting for SubmitterA and SubmitterB to decide if they agree that the 2 puzzles are indeed a duplication, the Reporter can follow the progress in their own Messages box. 

The Merge Request information starts by stating who reported it, and when it was reported. Newest requests are listed first.

The subsequent sections detail which puzzle is to be merged into which puzzle. The names of the puzzles are underlined, as they provide a link to the actual puzzle records.

The final section lists the status of the request. Both record Submitters are listed, alongside the status of who has agreed to the merge request, and who has yet to update.

 
Admin is also mentioned here. The IPDb Admin Team will monitor all Merge Requests and will need to consent to the merge as well after review.

The Merge Request will remain in the Reporter's message box for 8 weeks (56 days), giving them ample time to see which requests were denied, and for what reason, and which were carried out.

Additionally, the Reporter will receive messages in their normal inbox when the request status has been changed and when the duplication report has been resolved.

Regardless of whether or not a response has been received by the parties involved, the Merge Request will be executed or denied within 28 days.

This section explains how the Merge Request is experienced by the Submitters, in our example, SubmitterA and SubmitterB.

When a Merge Request has been created that involves a puzzle record of theirs, the Submitters or the records involved will receive a message, and a red notification number will appear on the review icon in their message box, as well as on the cog icon (settings) in the main App screen. This red number will remain for as long as the Merge Request hasn't been executed.  

The Merge Request is mostly the same as what the Reporter can see, but with one important difference - the buttons at the bottom.

The Submitter should carefully examine and determine whether they agree that the request is valid (that both puzzles are indeed duplicates) or if they disagree.

The Accept button will accept the request immediately and, as such, will change the status for that Submitter..

When clicking/tapping the Deny button, the Submitter is asked to explain why they disagree with the request.

If any of the involved parties deny a request, the request is closed, and the merge will not happen.

The request will remain in the message area for 59 days even if it is denied. So, if anyone feels that this is the wrong decision, they should open a Submit Ticket and send it to the IPDb Help Centre (via the '?' icon in the App).

The request will then be reviewed and updated.

The updated information is visible to everybody involved - all Submitters, the Reporter and the Admin Team.

If both Submitters and the Admin Team agree to the merge, it will happen within 24 hours after the last party has accepted the Merge Request.

If any of the Submitters or the Admin Team does not reply to the request, it will happen automatically after the 28-day waiting period.

Once the puzzles have been merged, all IPDb users who have added something to the most recent record submitted (E.g. Smoky Trian above) will receive a message in their inbox, explaining that their information regarding this puzzle now relates to the newly merged puzzle (eg Smoky Train above), and are encouraged to go and check that record to ensure everything is ok.

Sometimes, certain information cannot be transferred in the merge, mostly concerning information that is present in both puzzle records. For example, if a User has made a review for both PuzzleA and PuzzleB, then only the review of the original record persists, and the review of the puzzle that was merged will be lost. So it's most important that all is ok after a puzzle you have contributed to has been merged.