What Wildbook are you working in? ACW
What is the entire URL out of the browser, exactly where the error occurred?
Can you describe what the issue is you’re experiencing?
I’m trying to round up all of the data integrity issues in ACW so I can send them out to their respective data owners to resolve. In the list of Annotations with Multiple Individual IDs, I noticed a couple of examples where a single user ID has 2 Marked Individual records but both have the same default ID:
#4 on the list: 23a0ed86-f506-4e69-a118-bdca5a7895ca is assigned to both LP-BW-05M & LP-BW-05M, under the same user ID.
#7 on the list: 919619f7-56f7-40b0-bb30-58130bd1af9e is assigned to both Ke_SpH024_OJ & Ke_SpH024_OJ
How is this possible? I don’t understand what steps a user could follow that would allow them to have duplicate IDs under a single user ID.
I’m not sure if this is a bug, working as designed or a loophole somewhere in the code. To my mind, a user should not be able to create a new ID if it matches an existing ID under their user ID.
I’d appreciate some help in understanding what happened here so that I can either warn users not to do it or ask for a feature request (assuming it’s not a bug…)
I don’t think this was a result of user error. I suspect this is related to the conversation you had about the bug @CMKonrad flagged in Flukebook with duplicate Individual pages being created for the same animal. When I initially ran it by Jason, he saw it was happening at a larger scale in ACW. I’ll see if I can get an update on the status of that.
Quick aside: I recently learned we can force a merge between individuals. I’ve added instructions on how to do it in our new Merge FAQ.
We haven’t been able to reproduce the issue yet, but we’re working on it! That data you sent over when you last reported it is helpful and I hope it means we can make some progress soon.
Thanks for the tip about how to force a merge - that’s huge for our users!
I can reach out to the users who own these duplicate individuals and try to understand what process they followed that resulted in this duplication, although they might be completely unaware.
Paul did mention that one of the users (owner of the wild dog example) has a tendency to start adding manual annotations before a bulk import has completed detection, creating a duplicate encounter. I don’t know if this is what he did here and that would mean he’d uploaded the image as ID’d, which is also possible - he does that on occasion.
As for the other user, I have no idea what her workflow is so, as I said, I’d be happy to reach out to see if she can tell me what steps she took that might have resulted in this duplication.
And/or if there’s anything else we can do to try to help solve this mystery, please just let me know.
Oh, that’s interesting context. I’ll be sure to pass it along.
Jason suspects that it could be something like user 1 uploads a spreadsheet with user 2 listed as the submitter. Then user 2 uploads another spreadsheet, also listing themselves as the submitter. Any marked individuals that appear in both spreadsheets could then be duplicated (theoretically).
I don’t think that’s the case here. One of these users does all her own uploads, and the other has a colleague doing his uploads, except when he’s uploading a different dataset himself. Neither user, in these cases, is splitting a dataset with another user to end up with both uploading from the same dataset.
Per another issue posted by me: ACW: delete bulk import doesn’t delete all encounters, the incomplete delete of a bulk import, plus it’s re-import into ACW and re-Id’d might be a cause of the duplicate ID issue?
Examples and details are provided below, from the other ticket:
@Anastasia - this user has just pointed out to me that he now has duplicate individuals in the system so I think we may have found the (or at least a?) source of that issue?
Here are 2 examples of duplicate IDs from this user’s data:
Hope that helps!
These are still in progress, but the duplicates upthread have been resolved.
The duplicate records for MOL_HYEN_0523 and MOL_HYEN_0517 have been reconciled.