UUID instead of ID name (ex. CH00___) being displayed

Support
, ,
1

What Wildbook are you working in? ACW

What is the entire URL out of the browser, exactly where the error occurred?
Match #5 here: Wildbook for Carnivores
Displays the ID as a UUID rather than the standard name in this dataset (CH00----)

Can you describe what the issue is you’re experiencing?
The researcher is following a regimented approach to her matching in this dataset - she starts with an individual ID (in this example CH00060) and selects a viewpoint encounter and runs matching against it to find all the unassigned matches in the database. When she determines that a proposed match is a match, she confirms the match on the match page.
In this case, she’s found an ID’d individual listed in the potential matches (#5 in the url above) that doesn’t have the standard naming convention but instead has a UUID. When I look at that Marked Individual page, I see 2 encounters assigned to this individual.
I understand that this means that no CH00— name was assigned so the system applied a UUID but I don’t know how this can be done?? What user error can cause this to happen? And is there any way to figure out what the CH00---- id was originally?

These encounters were not uploaded with IDs - I can tell because the ID’d individuals in this dataset were uploaded without the Occurrence ID naming convention that you see in these two assigned encounters; they had random UUID strings for OccIDs. So somehow, these 2 encounters were assigned this UUID as the Marked Individual ID without the user noticing.

Is it user error or a system issue?

thanks
Maureen

2

Hey @ACWadmin1,
I am reviewing the import log for this bulk import (https://africancarnivore.wildbook.org/imports.jsp?taskId=cd4a2a2f-cf69-4c33-8ce0-d744e87579c2) and it seems like these encounters were uploaded with that UUID in the Individual field, which seems odd given the rest of the list either does not include and individual reference or follows the CH00 pattern. Do you have access to the file that was uploaded (ACW_cheetah_raw4_upload_K_Final2_last95images.xlsx)? That seems the quickest way to determine where in the pipeline the breakdown is.

Thanks,
Tanya

3

Hi Tanya, I think I still have the upload file; I’ll root around. But wow, would that be my dumbest moment so far this year if I did that…

4

Hey now, it is equally likely that we have a bizarre conversion error based on a random white space. :laughing:

5

Possible but unlikely :stuck_out_tongue_winking_eye:

I’ve just sent the file to services@ cc’ing you. At least I believe it’s the same file.

6

Okay, we have come to something of a conclusion.

  1. I need to document what is presented to the user in the bulk import log since I made some assumptions that were incorrect. Your import did exactly what it should, and did not include any individuals, so good to go there.
  2. We do not know what the previous ID name was for this individual. I have a strong suspicion that this got fussed with while we were resolving the issue that came up with IAResults showing UUIDs instead of names.
  3. To ensure we have traceability on this, we’re going to make sure the audit logs reflect name changes. It’s bizarre that they don’t. We’ll be tracking that under WB-1232.