Inconsistent "Encounter.photographer0.fullName" column upload results

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

What happened?
I did a bulk upload about half an hour ago and it picked up the column “Encounter.photographer0.fullName” no problem.
I’ve just tried to do another bulk upload, and the system is telling me that that column is not being imported. Why??? So frustrating.

What did you expect to happen?
I have emailed both spreadsheets used - the one that successfully uploaded the “Encounter.photographer0.fullName” is called “ACW_cheetah_raw3_upload_trial_Ian_Hicks.xlsx”.
The spreadsheet in which the “Encounter.photographer0.fullName” column is called “ACW_cheetah_raw3_upload EF”

Note that @PaulK also attempted a bulk upload right after my first one of the day (“Ian Hicks”) and his upload of the same column for “Encounter.photographer0.fullName” also got flagged as yellow in the bulk upload process.

What are some steps we could take to reproduce the issue?

If this is a bulk import report, send the spreadsheet to with the email subject line matching your bug report

Hey @ACWadmin1,
I just want to respond and let you know we’re looking at this right now and figuring out best actions/options. We should get back to you with either a workaround or a proposed solution soon.

I believe this is actually by design, though I would need to reproduce the actual order of imports and know whether the User account existed even before the imports to actually verify.

Basically, these fields:

  • Encounter.photographerX.fullName
  • Encounter.photographerX.affiliation
  • Encounter.submitterX.fullName
  • Encounter.submitterX.affiliation

Are unused by the import if the User can already be found in the database. If the email address does not link to an existing User, then those fields are added to the new User object created on import.

Ignoring those fields if the User already exists prevents over-writing any edits or changes that the User may have intentionally made to their User account.

I have updated the spreadsheet of importable fields to reflect this context.


Hello Jason

I am not following your response here.

Since we are updating the Encounter table thru the Bulk Uploads I would assume that this information is only stored at the encounter level and unless the system is doing some sort of validation against the master User table, why would it matter what the Photographer name and email is ?

In all cases only a registered User can use the Bulk Upload tool and will usually be the Submitter. If they are not using their own images then we need to maintain a record (if we have it) of who the photographer (IP owner) of the specific image (MediaAsset) is.

I do not foresee us having any photographers becoming Users of the system unless they are primarily already researchers.

Here is a sample bulk upload file where the Photographer name is not being accepted

By the way, we are more focused on the Photographer email address along with their name. Affiliation is less of a priority.

Happy to discuss further this week.



Happy to discuss in a call.

Every submitter and photographer is stored and parsed as a full User object, allowing us to track who has submitted what as well as concretely report engagement.

When we see an email address for the first time in a submitter or photographer field on a Bulk Import (or via submission page), such as “”, we will create a new User object and populate it as fully as possible, such as with related fullName and affiliation information. This is a full User account, but it has no roles and no username to login with. However, it can be modified to have such info in the future by an admin…providing a pathway for frequent submitted and photographers to get system privileges and even retain their data association.

However, after first User creation (requiring a unique email) from an Encounter.submitterX or Encounter.photographerX, we only look up the User object and don’t set any additional values, assuming that the User may have changed these values through the UI. It would be a nuisance for an User to correct their full name or their affiliation, only to find a bulk import changing it to another value. Thereafter if you want to change something about a submitter or photographer, you can look them up in the Users table and set related information (e.g., fullName, affiliation, profile photo, etc.) and see the change propagated everywhere that User object is associated.

Happy to talk it through over the phone.