Hi there,
You were correct in using the field name: Encounter.photographerX.fullName
Since that isn’t working, we’ll have to do some investigation as to what isn’t working. We’ll be tracking this with ticket WB-598
Thanks for reporting this!
Thanks for emailing me the file you are working with.
Fields for photographer are incremental and do require the number like so:
Encounter.photographer0.fullName, and so on.
Fields formatted like Encounter.photographer.fullName or Encounter.photographerName
do not have a reference and cannot be retrieved.
Also, I noted in the excel file that the email column was not filled out for the photographers.
The submitter, photographer and others to inform columns all require an email address.
This is because they reference a user in the system, or create a new one and we are starting
to require an email address for all system users.
Thanks Colin - I shall follow up and do a test on the upload shortly.
Where the Submitter is different than the photographer it may be that we do not have the Photographer email but still want to attribute image to the Photographer - is this hardwired in the system now to require the email address ?
Yes, we are requiring email address system wide for users. Photographers, submitters
and “Others to Inform” are saved as users in the system from import.
There’s a problem with this requirement for email addresses of photographers, as it relates to bulk uploads, particularly in ACW with our silo’d security. Bulk uploads are of images sent to a particular researcher (ex. Gabriele) or conservation group (ex. EWT). They share their emails with that org but are not agreeing to share them with ACW - privacy issue #1.
The next issue is that if one ACW researcher agrees to share their data with another researcher, I assume the photographer name and email are also shared. This is another privacy issue.
I don’t believe that privacy laws in Canada, US or Europe allow for us to add email addresses to the system without the knowledge or consent of the person to whom the email belongs.
Furthermore, in the situation where we do not have an email for the photographer (for some reason) we would then likely end up having to use a proxy email to be able to utilize those images.
Hey @PaulK ,
We’ve been working through this trying to figure out the best solution. This history is that, once upon a time, these weren’t associated with any accounts, which meant they couldn’t be leveraged for update emails and the like. Trying to better serve folks, these fields started to carry the same email requirement as any field that references a user.
At this point, we have a recommended workaround and an idea about how we want to fix this in the future. Workaround: input only the information you have, such as a name, and associate with a general non-user email. So, in your case, you could input an email such as anon@acw. That preserves the privacy of your users and allows you to store the information you do have about the submitters and photographers. I will be including this information in the documentation. Future fix: Refactor to allow non-user information OR reference a user account. This is a substantial change given how the system is currently developed, and we need to unravel some pieces to make sure we aren’t adding a whole new security issue in how our user requirements are managed.
This work is being tracked under WB-623.
