Match dropdown has duplicate of CH00033 & ID shows as alpha-numeric instead of CH00033

Bug Reports
2

Hi ACWadmin,

The system is actually responding normally. The individual with the long string of letters and numbers for a name (a UUID) actually has only that name set.

https://africancarnivore.wildbook.org/individuals.jsp?id=8a269cb3-5e0f-49f9-bb22-8da1bd26245c

A good nickname would make that far more readable. But that is technically all we have to list for it.

There are indeed also two CH00033 individuals:

https://africancarnivore.wildbook.org/individuals.jsp?id=07eb1c27-d61d-44e8-9919-36e5885849c7

https://africancarnivore.wildbook.org/individuals.jsp?id=253791ce-0029-4172-bc8d-de0dc3e9b13b

They should either be merged or one should be renamed, depending on whether they are the same individual.

So there are indeed three individuals being referenced.

Thanks,
Jason

3

Hi @jason, clearly I should have checked for this before submitting the ticket - apologies. But this raises some additional questions:

  1. Is there any other way to more easily merge the 2 CH00033 records other than:
    i) to run matching for one and sort through each of the proposed matches until we find one that’s assigned to the other individual? or
    ii) remove all encounters from the 1 and re-assign each to the other?

  2. What steps would have caused the UUID to be created?

  3. Am I correct in assuming that the cause of the duplicate CH00033 record is a result of the researcher having typed in the full ID on a match and not selected the ID from the dropdown list? If not, can you tell me what you think happened?

thanks
M

4

Regarding point 1: There is not. This is still something that is planned, and we have an open feature request for. We do not have a timeline for when it will be available.

5

There is a faster way than using the merge from matching. You can go directly to the merge page and put the UUIDs of the two individuals to merge into the URL, such as:

africanarnivore.wildbook.org/merge.jsp?individualA=XXXX-XXXX&individualB=XXX-XXXX

The UUID can be quickly found from the ?number=XXXXX field in the URL of each individual. That is the database’s name for the individual.

This feature is not fully intended to be exposed to users. But for admins who need to “just make these two individuals the same” it works nicely. It’s just forcing the issue that would otherwise emerge from the match results.

6

What steps would have caused the UUID to be created?

Every individual has a UUID. It is the true name of the individual in the database. In the case where the UUID appears for the individual, it’s because no other Default name or Nickname has been set. I don’t know the origin of this issue specifically.

Am I correct in assuming that the cause of the duplicate CH00033 record is a result of the researcher having typed in the full ID on a match and not selected the ID from the dropdown list? If not, can you tell me what you think happened?

Perhaps, or it could be holdover of the individual duplication that happened very early in the project. Either way, the link above should help you fix it quickly if you enter the UUID for each CH00033 into the individualA and individualB parameters of the URL.