Image field not showing photo/folder buttons

2643
9
Jump to solution
01-12-2021 04:29 PM
Alber_Verster
Esri Contributor

Hi All,

 

I encountered this strange behaviour and thought I would ask the community for some explanation why this is being experienced.

In a survey form, I have a photo field that is hidden unless the field preceding it is set to 'no'. When completing the form for a new feature, then the logic is sound, no issues encountered but when I use the Inbox to edit an existing feature, then the below behaviour is encountered:

photo-field-logic.gif

I would expect that one would not be able to edit a photo field in the form from an existing feature but when the yes/no question is toggled, then the photo/folder button do show and I am able to capture and successfully send the captured image.

Is this a bug or is there something else causing this?

Some insights would be appreciated.

Thank you in advance.

 

Tags (2)
1 Solution

Accepted Solutions
Alber_Verster
Esri Contributor

Hi George,

I believe that this is a cosmetic bug and is very likely not going to get solved any time soon. We are seeing this issue because Survey123 does not make any requests regarding attachments from the Inbox and therefore treats the field as not null, meaning we are not able to edit it (initially). Toggling the relevant field would override the dependency field's not null status, which would allow you to capture the photo but I believe in your case the best solution would be to put the photo field in a repeat table.

Hope that helps.

 

View solution in original post

9 Replies
BarbaraWebster1
Esri Contributor

Hi Alber,

Viewing and accessing attachments from the Inbox is not supported. This feature is currently in our enhancement backlog. 

Thanks,
-Barbara

0 Kudos
Alber_Verster
Esri Contributor

Hi Barbara,

Thank you for the response. I am aware that this is not supported but in the post I show that it is in fact do-able if the previous question is answered "yes" then "no", the the thumbnails do show and I am able to capture the image and submit it successfully. Why is that?!?

0 Kudos
JamieLambert
Occasional Contributor III

Hi @Alber_Verster,

You are just showing it is possible to take a photo in the Inbox without a repeat? None of your photos were actually attached to hosted feature were they? I had a quick look at this an no images were actually attached to my hosted feature.

Thanks, Jamie.

0 Kudos
BarbaraWebster1
Esri Contributor

Hi Alber,

Ah I see, I must have read your question too fast (sorry about  that). You can’t download attachments from the inbox, but you can upload attachments from the inbox, so I think what’s happening is that when the record is first opened from the inbox, the photo question appears blank since the attachment hasn’t been downloaded from the feature layer. When you toggle from no to yes, the contents of the photo question are cleared because of the relevant, which is why the upload/capture icons become visible.

Untitled Project.gif

GeorgeJoubert
New Contributor II

Hi Barbara,

I have a similar issue. In my case we are capturing master data. We have an approval process and a rejection process. Our Rejection send the survey back to the user's inbox with fields pre-populated so they have to capture a new photo. We have two fields we use.

1. User to Collect Data so only the relevant user receives it in his app inbox.

2. {requiredphotos} field set from the portal (in the app it is readonly)

The field is read-only and cannot be toggled so this is creating a problem. The photo field display slightly different on My app, but is creating the same problem.

Is this a bug in the system?  Attached is XLSForm and screenshots

 

Kind Regards,

George Joubert

0 Kudos
Alber_Verster
Esri Contributor

Hi George,

I believe that this is a cosmetic bug and is very likely not going to get solved any time soon. We are seeing this issue because Survey123 does not make any requests regarding attachments from the Inbox and therefore treats the field as not null, meaning we are not able to edit it (initially). Toggling the relevant field would override the dependency field's not null status, which would allow you to capture the photo but I believe in your case the best solution would be to put the photo field in a repeat table.

Hope that helps.

 

View solution in original post

BarbaraWebster1
Esri Contributor

Hi George,

The behavior you're seeing is because editing/adding attachments to a parent table from the inbox is not supported.

As Alber said, the recommended method for adding a new attachment via the inbox is to put the image question in a repeat.

Thanks,
-Barbara

0 Kudos
GeorgeJoubert
New Contributor II

Hello Alber and Barbara,

 

Thank you for the feedback. Sadly this is not what I want to hear. I managed to build in a toggle switch and it works, but what I found is as soon as you have the multiline function enabled; it does not upload the photos.

 

I have started off with the repeat function, but it is messy as each photo repeat function has its on column and reviewing the photo's via the portal is really not nice. I am not sure why the function is advertised, but still have so many bugs. I understand it does not totally match up with your original post Alber, but is related.

https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-photos/ba-p/897907

See my attachment XLSform, where photos do not upload. User to Collect Data is the userid of the person logging in. I also included a screenshot of how the attachments display in Application. (Repeat gives you sub folders.)

 

Kind Regards,

George

HarroldLikens1
New Contributor II

I wish this worked with the Inbox in the mobile app as well as it does online. I do have to say, the solution offering really isn't a solution to the image capture icon not showing up for an image question. I'm having a similar problem with an image question where a photo is required to support a failure in an inspection. The image capture icons do not appear unless you do as Alber does in his demo and toggle through the options. This is more of a functional problem not a cosmetic problem. 

I can't imagine telling staff to just toggle through two extra clicks to take a picture when they will complain (and count) the number of clicks it takes to complete an inspection. 

Thanks for the posts and I hope for continued support.

Regards,

Harrold