Strikethrough on Repeat Records

1224
8
Jump to solution
03-13-2018 12:30 PM
BradenBurkholder
Occasional Contributor

As of 2.6.7, I'm getting some odd behavior on required fields within repeats. Specifically:

1. When select_one fields used in the last record are selected, the answer shows with a strikethrough

   (but if the field was not used in the immediately preceding record (due to relevant setting), it looks normal)

2. Required integer fields are defaulting to zero - with no default value set otherwise

   (this is a bigger deal as zero can be meaningful as a value and a user may forget to correctly fill it in)

 

All data appear to be preserved and do not have strikethrough formatting if repeat records are reviewed (before submitting or from outbox). 

This may be related to another reported issue:

select_one choice strikethrough when opened by inbox 

0 Kudos
1 Solution

Accepted Solutions
BradenBurkholder
Occasional Contributor

Okay, I isolated the bug:

If within a repeat block and using a relevant expression and required = yes, select_one questions will appear with a strikethrough if using a minimal appearance. Likewise integer fields will be pre-populated with zeros. This has occurred with both selected() and string-length() relevant expressions. Having potentially false zeros in the survey is a rather unfortunate bug.

See attached example.

FYI: This occurred on a survey that had been working without error in previous versions of Survey123.

View solution in original post

0 Kudos
8 Replies
by Anonymous User
Not applicable

If it helps, I get this if I put a default like 'N' in a yes no list option which is an incorrect entry

maybe points you in a direction ,,

0 Kudos
BradenBurkholder
Occasional Contributor

Wow, I didn't expect that to work on an integer field.

I changed the default to 'n' and it shows up (in red) as the default in Survey123 Connect anyway. Haven't tested yet with publishing...

0 Kudos
BradenBurkholder
Occasional Contributor

I was able to publish a survey with "number" as a default value for the integer field, which should prevent erroneous zeros in repeats. Thanks for the tip, Mark.

0 Kudos
BradenBurkholder
Occasional Contributor

Okay, I isolated the bug:

If within a repeat block and using a relevant expression and required = yes, select_one questions will appear with a strikethrough if using a minimal appearance. Likewise integer fields will be pre-populated with zeros. This has occurred with both selected() and string-length() relevant expressions. Having potentially false zeros in the survey is a rather unfortunate bug.

See attached example.

FYI: This occurred on a survey that had been working without error in previous versions of Survey123.

0 Kudos
BradenBurkholder
Occasional Contributor

Using a constraint of '.>0' works as well for preventing zero values in one of my surveys.

0 Kudos
BrandonArmstrong
Esri Regular Contributor

Hi Braden,

Thank you for the information.

I wanted to let you know that I am actively investigating this behavior and will update after testing.

Brandon

0 Kudos
BrandonArmstrong
Esri Regular Contributor

Braden Burkholder‌ Thank you for bringing these issues to our attention. 

I have gone ahead and added the first issue into our internal backlog -  strikethrough appearance is seen with select_one questions that are within a repeat, required, and containing a relevant statement in records after the first.

Note:  This should not affect the ability to submit surveys nor the values that are submitted.

As for the second issue, where integer fields within a repeat that have relevant statements autopopulate a 0 on records after the first, this should be resolved with the next release of Survey123 (2.7). 

You can access the beta through the Early Adopter Community right now if you have an immediate need for the fix.  Also, you can checkout some of the other cool features coming with future releases of Survey123!

Thanks again for sharing your discoveries.

Cheers,

Brandon

0 Kudos
BradenBurkholder
Occasional Contributor

Thanks for the update Brandon!

0 Kudos