Select to view content in your preferred language

Constraint bug in URL version of Survey

497
3
01-31-2018 06:31 AM
Survey123Survey
New Contributor

Good day,

I think I'm experiencing a bug regarding how constraints work, in the UI on the URL of our survey.

The survey has a constraint that checks for no text in a calculated/hidden type. The text is an error message that only becomes visible if a user has not entered their name and employee number. This seems to work well in the preview and the app but when I publish and access the survey via the URL it accepts a blank number and name where as it should give some sort of validation error like the preview does.

Is this a known issue or bug? Anyone else experiencing something similar?

Thanks

Greg

3 Replies
JamesTedrick
Esri Esteemed Contributor

Hi Greg,

Great screen name!  Can you provide more details on how your form is structured?  I'm able to implement what you are describing (a field that checks for the presence of values in other fields, which then has a note to display a message); it works for both the web and app.

0 Kudos
SamuelRoss
New Contributor III

I am having a similar issue. Mine is I am trying to grab a geopoint but allowing them to also edit the location should they not be standing where I am asking for the geopoint to be. I have an error message that pops up when they select a point that it outside of Canada (really just a rectangle somewhat surrounding Canada). However when i am using the application this works great but as soon as it is in browser it does not seem to update any more than the "home" location (the default location I set). So whatever point they put in the message never appears. It seems to not (what i call) live update with each point they select. I have attached a screenshot of the code I am using in case that helps. one thing that does not show up in the screenshot is for row 9 in the constraint column I have entered; .=2

Thanks for the help

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Samuel,

Are setting the bind::type of the Allowed field?  If not, the comparison might be for '2' (string 2) - hidden fields have a default type of string (which is why the other calculations you have have type conversion).

0 Kudos