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
My researcher had reported some issues to me that I wanted to replicate with her on our weekly call this am. Her process for matching is to go chronologically through each ID’d individual’s record, select assigned encounters, run matching from each, for each L/R viewpoint, and find all of the unassigned encounters in the system that match, then, of course, match these unknowns to the target ID’d encounter.
Here’s the original match results link she sent me, which I used for all of the steps listed below:
The first issue found, reported as a bug by me yesterday, was that the assigned encounter that was selected was not the one that was being displayed in the match results as the target encounter. Instead, the system was displaying the unassigned copy of that same image.
It is expected for us to find a duplicate copy of ID’d photos in the system bec the ID kits each contain a re-named copy of the raw tourist pic. The raw tourist pic remained as is in the relevant sighting folder, which was uploaded, as were the ID kits.
However, we do not expect the system to swap the assigned encounter selected for match results, for the unassigned copy. I was able to replicate this issue so reported it yesterday.
This am, we found more bizarre behaviour.
From the same match results page, since we knew that the target image was CH00051 and the 1st match result of an unassigned encounter, was a match to the target, I did the following:
- I checked the box and went to select CH00051 from the dropdown menu in the top yellow bar.
- I typed in “CH0005”, selected CH00051 from the dropdown menu, clicked on
- Result: a UUID was displayed on the target encounter record as well as the matched encounter record.
- I clicked on the UUID to see if it took me to CH00051’s individual record. It did not. It took me to that new UUID’s individual record, with the 2 recently matched encounters as the only 2 in the encounters list for that individual. If this had been CH0051’s individual record, it should have shown at least 1 additional encounter in the list, since CH00051 pre-existed the match done above. It did not have any additional encounters in the list.
- I opened each of the assigned encounters (for the UUID individual record) and removed them both from that individual, effectively deleting that new individual.
- I went back to the match results page that we’d started with, refreshed it and noted that the target and the 1st proposed match were no longer assigned to anyone.
- I repeated steps 1 & 2 above. Again, this resulted in a UUID displayed as the assigned individual, rather than the name “CH00051”.
- This time, when I clicked on the UUID link, the individual record for CH00051 appeared.
- I scrolled down to the encounters list in this CH00051 record and it displayed only the 2 encounters that I had just matched, no other encounters were attached to this individual ID.
- I went back to the tab with the results page, refreshed it, hoping the UUID would disappear and the name CH00051 would appear as the assigned individual for the 2 matched encounters but it did not.
- I went to > Individuals > View all > filtered the results to find CH00051. The results showed that there was only 1 CH00051 record with only 2 encounters assigned.
- I went back to the 2 encounters that had been assigned through the steps above, and removed them from their assigned individual.
- Result (as expected): CH0051 no longer exists in the system.
But it should still exist since there were encounters assigned to it when the researcher, and I, initiated the matching in the first place. She selected an encounter from CH0051’s original individual record, ran matching, but ended up with a different, unassigned encounter, as the target image, but with the alternate reference box indicating that the image was a duplicate of one in an assigned encounter (which was the original encounter record selected to be the target).
So what happened to the original encounter(s) assigned to CH0051, uploaded as part of the ID kit?
Note that I previously reported a similar issue regarding CH00033 (Match dropdown has duplicate of CH00033 & ID shows as alpha-numeric instead of CH00033), but we made assumptions that the researcher had erroneously created a 2nd CH00033 record somehow, and that she had somehow either created or we had uploaded originally, an ID’d individual without a name, so the system displayed only the UUID in the other ID’d individual record.
Now, I suspect that what we saw then wasn’t user error or upload error, but rather the same as what I’ve described above.
This does not happen every time this researcher runs matching. She’s been going systematically from CH00001 to now CH00050+, following the same steps for each match run. This is only the 2nd time she’s encountered the results above.
Per above, I’ve asked the researcher to stop matching for now until we get some insight into this issue.
I’m happy to jump on a call to clarify any of the points above. I suspect, because it’s not happening every time the same steps are followed, this is going to be a tough one to investigate & resolve.