What happened?
Did a bulk import of ID’d individuals
Searched for encounters under the ID of the submitter
Search results table does not display occurrence ID’s for these uploaded records:
But it does display Sighting ID for encounters cloned from those original media assets:
I recall that @PaulK had reported this issue previously but I can’t find his bug report - hopefully there’s already a fix for this?
What did you expect to happen?
Occurrence IDs to display in search results
What are some steps we could take to reproduce the issue?
If you need the bulk import spreadsheet, I just sent it for a different bug report “Country not getting populated in system generated (cloned) annotations”
I believe this results when an Encounter points at a Sigthing, but the Sighting does not contain it. I do believe this logic hole was previously plugged, and a review of the current code suggests this should not be happening now.
I have prepared a quick, custom list of affected Encounters on your platform:
Can you please confirm that the listed Encounters should be associated with the listed Sightings? If so, I can enact the fix needed to make the associations. But since this does affect data, I would like your approval first.
Hi @MarkF & @jason - I’ve reviewed the list that Jason kindly put together and can confirm that all of the listed Encounters should be associated with the listed Sightings.
Meanwhile, I hate to say it but while looking at these encounters, I noticed that several were missing the Submitter contact info. In each case, it appears that all encounters in the related sighting are missing the Submitter contact info.
This is important to the researcher bec she’s using her ID as one of the filters for finding all unassigned encounters left in the dataset; so if some encounters are missing that, I’m guessing she won’t be seeing those in her filtered search results.
and verify that the Submitter contact info was specified. If it was, bulk import delete and reimport is likely to solve the issue as a lot of development has gone into bulk import since August when this import happened. If the issue persists, I would recommend a new ticket to address this issue.
Hi @jason - I checked the spreadsheet and the submitter ID was specified but not the submitter full name or the submitter email. I’m guessing that, even tho’ this info is already in the system from previous uploads & user profile set up, and despite the fact that the bulk import review page always says it won’t import the submitter full name field bec it’s already in the system, that this is the reason these sightings don’t have submitter info in the contact section of the encounters?
To delete the bulk import and re-import the spreadsheet only (with the additional contact fields added) - I see how that would work but will we lose all of the ID’s that have already been assigned in this batch?
I checked the spreadsheet and the submitter ID was specified but not the submitter full name or the submitter email.
Submitter email address (Encounter.submitterX.emailAddress or photographer email address, etc.) is the minimum field we need to create a new User and add it to the array of submitter, photographers, etc. Without that, I see why you’re seeing what you’re seeing. The importer would not have created the submitter if the email address is not specified on that Encounter row. Encounter.submitterX and Encounter.submitterID are not linked in the code in any way.
To delete the bulk import and re-import the spreadsheet only (with the additional contact fields added) - I see how that would work but will we lose all of the ID’s that have already been assigned in this batch?
Correct, you would lose curation work.
I think the best solution here is to fill these fields in manually if curation work has already been done on the data. There is not an easy solution on our side.