Hi @TonyDaSilva1 @E_-_MarieCook__GISS_ @GianniCampanile2 ,
Apologies for the delay in responding to this.
With 3.12, there was a change in how lists are managed internally. One of the changes addressed a set of BUGs that had been registered regarding the processing of choices with numeric values (for instance, numeric values being used in cascading selects); to address this, choice values are now being converted into a numeric type if possible. While we had this change in the Early Adopter Community for a number of months without issue, we are receiving reports in situations like you describe, where the values are number-like strings that have leading zeros. There are a couple of workarounds that can be used to ensure proper processing:
- If the number has at most 1 leading zero and a known length, it generally is feasible to have a subsequent calculation that prepends the zero by comparing the string-length value; for example, if an example value is 05678 (five digits with a leading zero), the function if(string-length(${q}) < 5, concat(‘0’,${q}),${q}) can be used to add the zero back to the string
- The choices could be altered to be processed as a string by prepending a character (such as ‘_’) and then a subsequent calculation removes the character: substr(${q},1)
Both of these workarounds uses a second, calculate question to process the value in the form; this can be used in combination with setting the select_one/select_multiple's bind:esri:fieldType to null so that the intermediate value is not stored.
Given the feedback, we are investigating ways that the type of value in a choice list can be better specified and hope to improve this.