[FR] Company Phone Number Validation

[arkajyotidas]

Please verify that this feature request has NOT been suggested before.

• [x] I checked and didn't find a similar feature request

Problem statement

We can add any type of character in the phone number field. It will be great if the phone number characters can be auto-validated after adding, like removal of extra spaces and unwanted characters.

Suggested solution

Changing the phone field from text to tel will resolve the issue.

Describe alternatives you've considered

Manually correcting the phone number then adding it

Examples of other systems

No response

Do you want to develop this?

• [ ] I want to develop this.

[SchrodingersGat]

Is there a single accepted standard for validating a phone number?

[arkajyotidas]

E.123 Format can be used, its an international standard.It uses space to seperate country codes but it can be altered with hypen.

[SchrodingersGat]

Would you be willing to submit a PR for review?

[arkajyotidas]

I am not good with Python web development

[wolfpackmars2]

E.123 is the standard for formatting (displaying) telephone numbers. E.164 is the actual standard.

E.164 limits phone numbers to 15 digits or less. The first two digits in E.164 format is the country code, and can more or less be used to provide guidance on how to display a phone number.

django-formset has a hone number field and stores all phone numbers in E.164 format.

django-phonenumber-field is a port of Google's libphonenumber library, which seems to underpin Android's phone number handling. Thus, it can be inferred that it uses a well proven methodology.

django's in-built form and field validation can be used to create custom validators.

Some More Information.

EDIT: I don't believe the E.164 standard provides for phone number extensions. However, until 1997 the standard was up to 12 digits, and I haven't found an example of an international phone number with more than 12 digits...

Seems like the common interface is to provide a drop-down to select the country, which helps guide the phone number format. I personally don't like drop downs (aka combo-boxes) as I don't find them conducive to rapid data entry, in my opinion.

[SchrodingersGat]

@wolfpackmars2 thanks for the additional context. Happy for someone to submit a PR on this

[wolfpackmars2]

I'm not currently planning to tackle this, as most of my vendors are web based and I don't deal with a lot of phone numbers.

@SchrodingersGat @matmair I suspect this FR will involve migrations of data that is not currently stored in a standard way. I'm not sure it qualifies for starter status, especially because it could impact existing data.

[SchrodingersGat]

@wolfpackmars2 thanks for your considered though on this. I do not think a data migration is required here - as updating the validators on a field does not re-run the validations on all existing database rows.

However there will be a schema migration required for the updated validator.

[wolfpackmars2]

@SchrodingersGat my thoughts were that to enable localization for phone numbers we would need to standardize on a format to store the phone number.

It might be possible to implement this with only changing the validator - which I'm guessing would be a strictly front-end change without changing how the value is stored. I haven't looked too deeply so apologies if I am mistaken - but I believe at present the phone number data is just a text field with no or little validation occurring to standardize how it is stored.

If the phone field is already stored in a standard way that would be compatible with the new validator, then yeah, a db migration wouldn't be needed.

At present I'm not planning on implementing this, but just in case it's still open when I could get around to it I'm flushing out my thoughts. Not needing a data migration would alleviate one concern I have.