Field behaviour on guest device registration/edit forms
07-16-2020 10:28 AM - edited 07-16-2020 11:10 AM
We are editing a couple of the existing forms in Guest (mactrac_create and mactrac_edit) for use with IoT device registration (MPSK SSID) (mactrac_edit needs to include an option for password reset). We want both forms to allow users to choose how to receive their password (SMS or email).
For mac_create I created a radio button field which gives them the option of having the device password delivered by email or SMS. Once a selection has been made the appropriate field should become enabled (ideally the field should also be hidden until this selection has been made, but for now...). I nicked a bit of JS from a different field which seems to do the job:
(typeof(mpsk_refresh) == "undefined" || Nwa_GetInputValue(mpsk_refresh) == "refresh-sms")
and a similar one for the email field.
This sort of works - the fields remain disabled until you select 'email' or 'SMS' from the radio group. But as long as you make a selection the form will happily submit, even if you don't fill in the email/SMS field. The fields are using built-in validation for email and phone numbers, but obviously this doesn't check for the empty string.
So I tried making the fields 'required', but that failed because even if you fill in, say, your email address the form complains that the SMS field is empty (even though it isn't enabled). So it seems as if fields that are not enabled are still submitted?
Am I approaching this the wrong way? Essentially I just want the chosen field to submit, and it should not allow an empty string. The field that is not chosen should not be submitted.
Any advice much appreciated
Re: Field behaviour on guest device registration/edit forms
07-16-2020 02:42 PM
Thinking about this some more I decided to avoid giving the option of 'either/or' email/SMS. Instead I used a 'required' email field and an optional phone number field. This seems to be an ok compromise... unless of course someone doesn't have an email account! (I could swap it I guess)
But if anyone has any tips about how we might manage to achieve the plan described in my first post - allowing someone to choose either email or SMS for password delivery (and allow them to supply values for those, with empty string check and validation for email/phone number) then I'd be interested to hear it.