2 identical marked individuals?

[ACWadmin1]

In which Wildbook did the issue occur? ACW

What operating system were you using? Win 10

What web browser were you using? latest chrome

What is your role on the site? admin & researcher

What happened?
Tried to assign an encounter to a known individual “Aspen” and discovered 2 Aspens in the system, with the same Default ID:

Interesting to note that one of these ID’d Aspen records is not showing any encounters on the Individual page. I know it says “not all encounters may be visible” but none is unusual, I’ve

This should not be possible? Not sure how it could have happened - thoughts?

thanks
Maureen

[PaulK]

And here is another one.

[ACWadmin1]

And a few more, from a review of all ID’d animals in ACW:
DBF1403 (Suntan) - 1 has 5 encounters; the 2nd has 2 encounters
MNF1702 (Hillary) - each record has 2 encounters
MNF1706 (Mallory) - each record has 1 encounter
MNM1704 (Chiounard) - each record has 1 encounter
MNM1711 (Anker) - 1 has 3 encounters; the 2nd has 1 encounter
Shishen - 1 has 1 encounter; the other has 2 encounters
Abel - 1 has 9 encounters, the other has 1 encounter

With the Mamacita records, the ID was not in the bulk upload, it was only added as an ID in ACW.

I hope all of this info helps with the diagnostics.

thanks
Maureen

[ACWadmin1]

After filing the list of additional dupes above yesterday, I remembered an upload I did in Feb of missing ID’d dogs in ACW. The pics were in the same folders as all the other ID’d dogs that were originally uploaded earlier last year but I couldn’t find them in ACW. So I did an upload of them in Feb. I’ve sent that upload file to the services@ email. It’s not a 1-to-1 match for the list of dupes above but there is overlap. Hopefully it’s part of the puzzle and not a red herring.

thanks
Maureen

[MarkF]

Hi, @ACWadmin1 !
I’m looping back through really old community posts that look like they slipped past us. Is this still an issue?
Thanks,
Mark

[ACWadmin1]

Hi @MarkF - this is still an issue. If you log in and search for these various individuals using the magnifying glass search function, you will see what we see.

Maureen

[MarkF]

Hi, @ACWadmin1 !

I think that I was finally able to reproduce the issue!

At least one way to reproduce the problem is this:

1. Mark an individual as new from a project.
2. Remove that encounter from the project.
3. Navigate to that encounter, remove it from the individual that was just created for it.
4. Re-assign that encounter to an already-existing individual.

For some (I’m sure totally and completely crazy) reason, under these circumstances, a NEW individual with the same name gets created, rather than the expected behavior of simply attaching the encounter to the individual that already exists in the database with that name.

I first noticed this issue upon inspection of the duplicate individuals… every one I looked at (which, granted, was not exhaustive) showed that at least one of the two individuals had a history in which they were part of a project but eventually removed from the project.

Whether this is necessary to create the duplicated individuals scenario is still unclear to me. But it does appear to be sufficient to create the duplicated individuals scenario we’re seeing above.

I’m filing a ticket for this as WB-1893. It seems gnarly, non-critical, and has a workaround, so I can’t offer a useful estimate of when someone will attack the issue.

In the meantime, here’s a workaround for merging individuals:

Copy the individual ID from one of the two duplicates from its URL. For example, 2aa62a58-bf80-4829-a428-b2e2822fa496 in:

Then copy the individual ID from the other of the two duplicates from its URL. For example, 17c7bbdf-1a8d-46fe-9e34-e4a7519f4350 in:

Go to the following URL:

Wildbook for Carnivores | LoginwhateverTheFirstIndividualIdIs&individualB=whateverTheSecondIndividualIdIs

. From there, you should be able to merge the two individuals into one individual.

I believe that I have ruled out bulk import as a culprit. Or rather, I at least have a counterexample that I used that did not produce a duplicate individual. This certainly doesn’t exculpate bulk import.

I have also ruled out simply assigning an encounter to an individual that already exists; in this case, it behaves as expected and just adds that encounter to the individual’s encounter list.

I still would like to do a little bit more investigation of the submitterID stuff that was mentioned in the related post Missing submitter ID causing duplicates in new ID uploads - #4 by ACWadmin1, so I (or whoever else takes on this ticket), will still have some investigation and follow up to do on that front.

I hope that this at least provides you some insight and a workaround.
-Mark