Make all zip code text entries require 5 digit entries, if numbers are entered

[cusackjm]

For all zip code responses in Module 4, if numbers are entered, 5 digits are required. Error message should not pop up if the zip code response is left blank (non-response)

[cusackjm]

Module 1: ALTADDRESS2

Module 4: HOMEADD1_1 - HOMEADD1_11 HOMEADD2_1 - HOMEADD2_11 SEASADD1_1 - SEASADD1_10 SEASADD2_1 - SEASADD2_10 CHILDADD1 CHILDADD2 CURWORK1 CURWORK2 PREWORK1B PREWORK2_1 CURSCH1 CURSCH2

[boyd-mj]

@anthonypetersen & @danielruss is there a function we can use for this? We aren't aware of a way to limit a numeric response to a specific number of digits. Thanks!

[anthonypetersen]

@boyd-mj I know we have minlen and maxlen but I think that only works for text fields, @danielruss can you confirm?

[danielruss]

@anthonypetersen @cusackjm The coding for [HOMEADD1_11?] in module 4 is coded properly as a TEXT input. You should not use numeric input because for example Manalapan, NJ has zip code: 07726 .

The you can add minlen:5 maxlen5. Try this in the dev tool:

[Q1] what is your zip code |__|minlen=5 maxlen=5|
[END] bye

[danielruss]

if absolutely needed, we could add a |zipcode|id=xx |, but this would be VERY US centric and I dont want to learn postal codes from around the world.

Another solution would be: |__|pattern=[0-9]{5}| but this prevents the user from moving forward without giving an error message.

[huip-ims]

@danielruss Daniel - As you mentioned, zip code is currently coded as a TEXT input. What Julie was asking is, if the response entered in the text box are all numbers, is there a way to check to make sure only 5 digits are allowed. However, if the zip code response is entered as alphanumeric or left blank, then the 5 digit check is not needed.

[danielruss]

Thank you for clearing it up. No we dont have one. Let me look into the validation and make a suggestion.

[danielruss]

@anthonypetersen @joearmani I like the idea of using pattern=. The issue is how do you handle the validation error for the user. The spanish/english is going to be a problem. We could add a uszip attribute but it is VERY us specific. ideas?

[danielruss]

@all There are multiple places we make assumption of us locality (SSN, phone number).... We will need to fix this. But until then zip code is one more thing that is us centric. I put in a fix into the zip branch that allows a question of the type:

[Q1] what is your zip code |zip|id="i_am_a_little_zipcode"|
[END] bye

This matches the |SSN| and other types of questions. No markdown is "broken", but all the zipcode question should be changed to use the new markdown. Because of the language translation - it is not ready for production. To match our other error messages I went with: Please enter a zip code in this format: 99999 However, we should change it to translate("validationZipCode") with approprate keys in the en.js and es.js files.

[joshid-ims]

I am a bit confused. Is this on NCI's court to fix this or should we be add this |zip| format to all questions in the markdown anyway?

[boyd-mj]

@anthonypetersen @m-j-horner @cunnaneaq we would like to discuss this on our 3 pm call tomorrow. From the other issue (#456) it looks like the dev team was waiting on a Spanish translation to finalize this new function. We've done very basic functionality testing in the renderer and it does work to limit the response to zero or 5 characters. Should we be making code changes to use this function for all zip codes in the English/Spanish Baseline surveys?

[boyd-mj]

Per Marie-Josephe after discussion on meeting 10/8, we will leave the zip code field as a text (alphanumeric) field with no limit to accommodate non-US zip codes - no code changes needed.