KT Walrus Posted June 11, 2017 Posted June 11, 2017 To support Authy 2FA, the Authy forms were upgraded to support selecting the Country Code when entering a Telephone number. The Tel.php form helper was not upgraded to generalize the Country Code feature. Rather, it is just a simple rename of the Text form helper. Please consider upgrading Tel.php to be a full Telephone input helper so custom profiles w/ Telephone fields handle Country Codes and input validation as well. As it is now in 4.2, the Telephone custom profile field is just a Text input field. It doesn't even validate that the text entered is actually composed of digits. That is, I can type in "My name is Walrus" and it is accepted. I can enter a regular expression for the Text input, but the Commerce IPS4 app doesn't even provide any additional validation (as far as I can tell by testing with a Customer Telephone field in the new Profile Completion feature). When testing, I set up a Profile Completion step to require the Customer's Telephone number. It allowed me to type in garbage and when I hit Next, it marked the step as complete and didn't let me go back and correct the error. Telephone Numbers should have JavaScript validation so the user doesn't make a mistake and just not realize it. Therefore, I'm requesting that you include a full-featured Telephone Number helper for Custom Profile fields and any other places in the suite where the user is requested to enter a phone number.
Mark Posted June 11, 2017 Posted June 11, 2017 The Telephone input type deliberately just uses a HTML5 input form with the "tel" property. Browsers can implement this how they like, but generally only use it for controlling what kind of keyboard to display on mobile devices. From the specification: Quote Unlike the URL and E-mail types, the Telephone type does not enforce a particular syntax. This is intentional; in practice, telephone number fields tend to be free-form fields, because there are a wide variety of valid phone numbers. Systems that need to enforce a particular format are encouraged to use the pattern attribute or the setCustomValidity() method to hook into the client-side validation mechanism. Authy requires the number to be in a specific format using a specific list of valid country codes. We did consider baking this functionality into the Telephone helper class, however, for the same reasons the HTML spec decided not to restrict it, decided against it - for example, we often have people enter numbers with extensions in our own client area.
Tracy Perry Posted June 11, 2017 Posted June 11, 2017 1 hour ago, Mark said: for example, we often have people enter numbers with extensions in our own client area. But could that not be a subset for the telephone field? In a similar vein, it would be nice for address fields to have the same subset for suite/apt #'s.
KT Walrus Posted June 11, 2017 Author Posted June 11, 2017 1 hour ago, Mark said: The Telephone input type deliberately just uses a HTML5 input form with the "tel" property. Browsers can implement this how they like, but generally only use it for controlling what kind of keyboard to display on mobile devices. From the specification: Authy requires the number to be in a specific format using a specific list of valid country codes. We did consider baking this functionality into the Telephone helper class, however, for the same reasons the HTML spec decided not to restrict it, decided against it - for example, we often have people enter numbers with extensions in our own client area. Obviously, I do not agree with you. IPS4 should provide top-notch form helpers. If you want to relax the rules for entering numbers with extensions, then this should be an option to the form helper. I just did a quick Google Search and found this active GitHub project: https://github.com/jackocnr/intl-tel-input It seems to be a rather full featured jQuery international telephone input library that could easily be integrated into the Tel.php form helper. I think it would be pretty easy for IPS 4.2 to use such a jQuery library to build a great user experience and not just fallback to a simple Text input field.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.