Querying INBOX

[Anonymous User]

Hi all,

1. How could I query empty values for a particular question?
2. According to this article, I should be able to use Creator={$username} to query all records created by the currently signed-in user. But, I get this error instead.

Any suggestions

Thanks,

Gee

[Anonymous User]

Hi Jack,

Yes, to run queries using logical SQL operators, your organization's administrator must disable the Standardized Query security option for your organization to allow nonstandard SQL queries. The above where clause you are trying to run is classed as a non-standard SQL query and therefore does require disabling the Standardized Query security option.

Phil.

[BrianBerdel]

Hi Phil,

I'm actually trying to do the same thing with Assignee LIKE ('%' + ${username} + '%') in a survey123 Inbox, I see you say about Disabling Standardized Query security Option. How do I get to that point though? I found this Help Page but the link they provide doesn't lead anywhere - https://gisserver.domain.com:6443/arcgis/admin

I've been googling for a while and cannot find how to login to the correct page to disable this option.

Any help would be appreciated thanks.

UPDATE:  It seems there's a conflicting message here concerning disabling standard queries.  On one hand we're told we need to disable standardized queries in order to use the ${username} function in a query, then we're told it's no longer an option in ArcGIS Online as of June 2020...

FAQ: What are the implications of the June 2020 ArcGIS Online Standardized SQL Query Enforcement? 

We're at a crossroads here where we've got 15 field user licenses that are mostly useless if we can't query the inbox by username.  This thread and others have been clear that standardized query needs to be disabled but there needs to be some guidance on how to use that username function now that we can't disable standardized query security. 

[Anonymous User]

Thanks Philip Wilson‌ for the help.

I'm thinking of creating a survey on top a "hosted feature layer" and definining features accordingly.

P.S. any updates on when the next version of Survey123 will be released 

Thanks  

[IsmaelChivite]

Hi geethaka.fernando_ACTGOV‌,

   version 2.7 is planned to be made available on April 3.

[Anonymous User]

Quick Question on this subject matter. I had a survey with the inbox enabled and the following "query allowUpdates=true" within the "bind::esri:paramters" column for a repeat that gave us the ability to pull all data and update values for the survey.

After the update to Version 3.0 we can no longer use the "Inbox" to update our data within repeats? Can you provide any feedback on what has happened as I am following the this help documentation - Prepare for editing existing survey data—Survey123 for ArcGIS | ArcGIS 

Thanks!

Mike

[Anonymous User]

Try deleting and re-downloding the survey.

That did the trick for me.

Gee

[Anonymous User]

Unfortunately, I just tried that and I am not having any success. Thanks for the suggestion.

[BrandonArmstrong]

Hi Mike,

If you are able, can you please share your XLSForm?  Feel free to send it in a private GeoNet message after clicking on my name.

Thanks,

Brandon

[BrandonArmstrong]

Hi Mike,

Thank you for sending over your XLSForm.  As we discussed, one thing that was noticed is that the parameter specified in the bind::esri:parameters column for the begin repeat question type of your first repeat was set as 'allowUpdates=true query'.  It was recommended that this be changed to 'query allowUpdates=true'.

After republishing your survey and downloading to the Survey123 field app, you have reported that the behavior remains the same.

For clarification, is the inability to edit repeats from the Inbox seen with all repeats, or just those that have a relevant statement applied?

If you have not seen the following GeoNet thread, there is currently a known issue involving the inability to edit the first record within a repeat when attempting to do so via the Inbox/Sent/Draft folders.

Best,

Brandon

[Anonymous User]

Hello Brandon,

I applied the above fix and I am still still experiencing the behavior of the repeat data not being queried within the inbox. However, this is occurring for all of the repeats within the survey form and not the one that had the incorrect query string. We have three separate repeats that contain multiple entries within them and none of the data has been pulled into the inbox survey forms.

However, we are "not" experiencing the issue of not being able to edit the first record of the repeats within the following workflow -> open a survey from the draft folder, choose option copy into a new form, and then the field crews will delete all entries into the last two repeats and not the geopoint repeat; as it contains the locations that are needed from the previous survey.

Thanks for the reply,

Mike