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

In which Wildbook did the issue occur? ACW

What operating system were you using? Win 10

What web browser were you using? Chrome Version 86.0.4240.111

What is your role on the site? admin + researcher

What happened?

  1. Ran matching for an un-assigned encounter
  2. Visually confirmed that the target image and match #2 in the list are both individual CH00033
    https://africancarnivore.wildbook.org/iaResults.jsp?taskId=aec83f2e-2b74-424f-8e79-12a148578d3c
  3. Started typing in the ID in the “set individual in both encounters” dropbox
  4. System displayed 2 items in dropdown - both CH00033
    image
  5. Selected 1st CH00033 from the list of 2 and confirmed
  6. Both encounters did not show as assigned to “CH00033” but rather assigned to an alpha-numeric string which I hope is the system unique ID for CH00033. Even after refreshing the results page after step 5 above, the alpha-numeric string remained on both encounters, rather than “CH00033”
    image
    What did you expect to happen?
  7. Only 1 instance of CH00033 in the dropdown list
  8. The ID on the encounter link in the match results to read as CH00033 rather than an alpha-numeric string.

cc: @PaulK

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.

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:

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

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

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.

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.

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.