What web browser were you using? Chrome Version 86.0.4240.111
What is your role on the site? admin + researcher
What happened?
Ran matching for an un-assigned encounter
Visually confirmed that the target image and match #2 in the list are both individual CH00033 Wildbook for Carnivores
Started typing in the ID in the “set individual in both encounters” dropbox
System displayed 2 items in dropdown - both CH00033
Selected 1st CH00033 from the list of 2 and confirmed
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”
What did you expect to happen?
Only 1 instance of CH00033 in the dropdown list
The ID on the encounter link in the match results to read as CH00033 rather than an alpha-numeric string.
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.
Hi @jason, clearly I should have checked for this before submitting the ticket - apologies. But this raises some additional questions:
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?
What steps would have caused the UUID to be created?
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?
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:
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.
