Phone # Digets

[plmok61]

The website will accept and number of digets greater than 6. Including area code all US phone #s have 10 digets. Low priority?

[kylecrum]

Phone number digits vary greatly from country to country. If you were to put in an international code, for instance, there would be 3 more digits. I think it's best to allow a wide variety here.

[drhenner]

Right now we only accept orders / addresses from the United States. Until that changes We should keep a US-only regex... That said I don't recall what the regex will accept or reject.

[drhenner]

I added the regex 2 or 3 years ago. :smile:

[kylecrum]

@drhenner , if it's US only, then it should require at least the area code (9 digits) and specify so in the form. Low priority, but should be an easy fix.

[drhenner]

Agreed. You are the first to inform me of the regex having issues. I added it 2 years ago and I think I got the regex from some contributor to the base platform (and they are all from other countries) =)

Throw in a fix. It will be easier to add now than after we have data. Thanks

[kylecrum]

Now that I think about it, I think that it should pretty much accept anything between 7 and 20 characters, unless a valid phone number is really needed from some business / fraud prevention perspective. People could put in extensions (e.g. 123-456-7890 ext 94 OR 123-456-7984x94), etc that it's probably better to be permissive and let people enter in 312-COOL-GUY if that's how they like their number. If there's an explicit business case why it is important that we need to validate phone numbers to a T, then I'm all ears. Otherwise, I'm leaning on the permissive side.

[drhenner]

The most fancy thing I have done is accept 10 or 11 digits. normally i strip out non-characters and store just the digits. If you take extensions you have a second field for the extension.

[kylecrum]

Right. I just think unless there is a specific business reason that we need to ensure the validity of phone numbers to an exact specification, then we should let it be. Easier on the users and less for all to maintain.

On Saturday, April 13, 2013, D. R. Henner wrote:

The most fancy thing I have done is accept 10 or 11 digits. normally i strip out non-characters and store just the digits. If you take extensions you have a second field for the extension.

— Reply to this email directly or view it on GitHubhttps://github.com/drhenner/fit/issues/113#issuecomment-16337771 .

[drhenner]

agreed. I'd actually say remove phone numbers but... :smile:

Less is more in this case

[drhenner]

Based on everything said... Should we just validate 10 - 25 digits and save exactly as the user types?

If we save just digits then 1-912-911-9111 x234 would not display correctly.

Thoughts?

[kylecrum]

I say just validate 10-25 digits and save whatever the user types. Again, unless there is a specific reason that we need to know it is a valid number it's probably best to make sure we are registering people with less friction.

On Sunday, April 14, 2013, D. R. Henner wrote:

Based on everything said... Should we just validate 10 - 25 characters and save exactly as the user types?

If we save just digits then 1-912-911-9111 x234 would not display correctly.

Thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/drhenner/fit/issues/113#issuecomment-16346742 .

[kylecrum]

Actually, to send this for 3PL integration, we'll need to make sure that whatever value we get, we can reduce it down to a string of 10 digits. E.g. if we store (123)-834-1904, that's fine as we can just strip the non-integer characters but 1-(123)-283-1983 would be a little more difficult.

I would say the rule would be, there should only be 10 digits present in the number.