Survey123 Converting Characters to "%code"

2745
12
01-05-2018 11:16 AM
KennethCompton
New Contributor II

Hey Survey123 folks,

I have an issue with a survey that produces a "%code" error for various characters when I try to populate fields in the form. 

A simple example of this is an email. The Email can read example@email.com but Survey123 will populate example%40email.com instead. 

Other characters that change include periods "." and colons ":" 

Some of these fields are auto-populating from concatenated fields. 

I saw this was a known bug in another post, but can't seem to find the fix/solution. 

Thank You for all your help,

Ken C. 

12 Replies
EmilyCaruccio
New Contributor III

I have the same issue. 

When I configure a Web Map pop-up with a custom URL scheme, if there is a comma within the attributes string %2C will appear in the auto-populated in the form/results. In addition, if there is a colon %3A appears.

0 Kudos
by Anonymous User
Not applicable

Hi Kenneth,

How was your survey created, via Connect or the Website? Where are you seeing the html coding error, on display inputs or submitting survey in the webform, in the mobile field app or viewing data on survey123.arcgis.com website, if so which part?

Regards,

Phil.

0 Kudos
KennethCompton
New Contributor II

Hey Phil,

Thank so much for getting back to me. I don't think the issue is with how the form was created. Long story short it was created in both because I tried the website got that error then tried the Connect and got the same error.

I am seeing the error when I display the form after I link it through ArcOnline "Create Template"

In ArcOnline I only have two feature classes. One for the form and another for the data I am displaying and using. I am "Creating a Pop-up Template" that uses the second features class to auto-populate parts of the Survey123 form. 

Example:

Name

Address

Phone #

Email

The auto-population works great, but this is where the code or syntax messes up and I see %40A, %3C, Etc... for characters it doesn't like (#, :, etc...) in the auto-populated fields. 

So the email fills out Example%40Aemail.com instead of Example@email.com.

or Phone%30C instead of Phone #

I hope I explained that a little better. Let me know your thoughts.

Respectfully,

Ken

0 Kudos
by Anonymous User
Not applicable

Hi Ken,

Thanks for the extra information. Yes, this is a known issue which we are planning to fix in a future release. It is in our backlog and I have added your comments to the issue.

Regards,

Phil.

EmilyCaruccio
New Contributor III

Hi Phil,

I am happy that this fix will soon be made. I was curious if there is an idea of when this future release will be?

Kind Regards,

Emily

0 Kudos
by Anonymous User
Not applicable

Hi Emily,

At this stage we are aiming for our 2.7 release, which will be released sometime in March 2018, however that could change based on other competing factors.

Phil.

ChristopherRodgers
New Contributor II

Hello Philip, can you confirm if you will also be supporting the ability to pass open and closed braces (squiggly brackets {} ) from Collector to Survey123 ? It seems there are some scenarios where GlobalID values are not passed properly via the CustomURL. I have a project where at least 110 of the 1,260 surveys that were collected seem to contain errors in the GlobalID that was copied. I have an open case about this if you would like more details about the issue.

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Chris,

On curly braces, there are differences on how the value is presented over URL depending on the originating application - Collector does not send over the braces, while Explorer does.  For now, We suggest the following to eliminate the differences:

1. Have the value load into a hidden question with fieldType of null .  Let's call this question incoming.

2. Have the question storing the globalid by a calculate question that checks for curly braces and removes if present:

if(regex(${incoming}, '^\{[\w\-]*\}$'), substr(${incoming},1, string-length(${incoming}) - 1), ${incoming})

Survey123 will do this check automatically in a future release.  In the meantime, to recover the surveys that are unable to be sent, I might suggest extracting the surveys using GitHub - tedrick/ReadS123DB: Convert the survey data stored in the Survey123 Field App into a set of...  and then appending them in.

MikeOnzay
Occasional Contributor III

I also have this question. From a map I'm passing a custom URL to S123. What you see below is the link address. Although when I view it in Chrome I see the actual values just above the bottom of the screen. The only % code I see is for the field metersize2. Everything else is clear and it all passes without an issue. Except for the metersize2 where I have a calculation that cleans it up. 

arcgis-survey123://?itemID=xxx&field:ServiceAddress=38%20WOOD%20LN&field:MeterNumber=99999477&field:MeterSize2=3%2F4%20INCH&field:MeterModel=SENSUS%20RADIO%20READ&field:MeterMXU=14125891&field:AccountNumber=0301-000269&field:MeterInstallDate=1218758400000

Today I added a second custom URL to this map in the same popup window to open a different form and this one passes the values with lots of % codes and some single quotes. This is what I see in Chrome for the link address:

arcgis-survey123://?itemID=xxx&field:ub_account_number=',%240301-000269,'&field:ub_service_address=',%2438%20WOOD%20LN,'&field:old_meter_number=',%249999477,'&field:old_mxu_number=',%2414125891

It is passing from the same source fields. The only difference I can see is that the destination fields in the other form have underscores between the words. Just in case there was an issue with these two links being in the same popup window I put the second custom URL in a different layer's popup window in this map and I have the same problems.

0 Kudos