Open atm-florianm opened 3 months ago
good idea. Have in mind that you can not assume that the country code address and phone number will match.
@eldy any thoughts about this standardization of all phone numbers across Dolibarr ?
A phone format is not something a user need to change everyday. So do we really need to use a database for this. A text file (xml, json, csv) looks a more oragmatic choice for such a need ? Or we can add a column in the existing table of countries. Why not a json with possible format descriptions as a text field in country tables. Adding a table for this, seems a bazooka to kill a fly.
Or we can add a column in the existing table of countries
A single column with just the country code wouldn't work for the few countries that have more than one code (Dominican Republic, Puerto Rico and Saint Helena).
I like your other suggestion better : with a json-encoded column, we could leverage DB engines' json capability (although from what I've read the json queries of mariadb and postgres seem to have very very different syntaxes).
A single json file stored outside the database could also work, but I can't find any benefit over a database table. If a table seems too much, maybe it could be created only when the user activates the feature?
Why not use https://github.com/giggsey/libphonenumber-for-php ?
Hello Just a question : In my case I have customers in Ile de la Réunion (+262) or Ile Maurice (+ 230) but registered with a China phone (+86). Will you check the phone number from the postal address, or will the prefix be mandatory regarding the country address?
Tks for reading
Or we can add a column in the existing table of countries
A single column with just the country code wouldn't work for the few countries that have more than one code (Dominican Republic, Puerto Rico and Saint Helena).
I like your other suggestion better : with a json-encoded column, we could leverage DB engines' json capability (although from what I've read the json queries of mariadb and postgres seem to have very very different syntaxes).
A single json file stored outside the database could also work, but I can't find any benefit over a database table. If a table seems too much, maybe it could be created only when the user activates the feature?
We are speaking of storing a prefix code for phoning. We already have a table with countries. We know 1 country can have several code but never thousands... We also know we need to read this code but not make search from it. So I suggest to add a column varchar where we can store the list of phoning prefix codes separated with simple comma...
Feature Request
It would be interesting to have an optional conf for validating telephone numbers (in contacts and third parties).
It would include a phone number parser, a formatter for the database (Dolibarr already has a formatter for grouping digits when displaying a phone number for some countries).
I am aware that international telephone numbering standards are complicated; there are many edge cases (national specificities, countries with more than one international calling code, private telephone networks with different numbering rules, ever-varying national conventions for writing / dialing numbers…) but since it would be conf based, we could start by covering the most common cases and then extend it gradually.
Use case
Some companies use Dolibarr a lot and have many users with privileges to add contacts or third parties.
Sometimes, modules provide services that require a valid telephone number from a contact (for instance an external API that wants to do two-factor authentication, or a VoIP module that allows users to dial from Dolibarr, etc.).
For such companies, it can be very useful to control the validity of phone numbers entered by users, and to store those numbers in a uniform international format rather than free-form format that may have implicit elements like national or regional prefixes whose meaning could be ambiguous.
Suggested implementation
First step
The first step would be a dictionary of international subscriber dialing codes (like 33 for France, 49 for Germany, 1 for USA etc.). I think an
entity
column is not required because those prefixes are supposed to change only when the international bodies (the ITU) make decisions, not depending on entities.For one of our modules, we have already started by declaring a dictionary like this (due to time constraints I didn't name the column and the dictionary consistently).
The dictionary we implemented only has 1 data column (the others being foreign key and technical ID), but I think it could be interesting to have more column for additional data, like validation regexps, minimum and maximum number of digits, etc.
Some (unfortunately not all) useful and official country-specific information can be found here.
We could also take data from already existing libraries to avoid reinventing the wheel (like Google's libphonenumber). Unfortunately, the latter is written in Java and the data is (apparently) in a custom binary format, not easily extractible (I'd have preferred JSON).
llx_c_calling_code.sql
key:
data:
dictionary declaration
Suggested steps
<input type="tel">
for telephone numbers on cardsphonenumber.class.php
) to parse, validate, uniformise and pretty-print phone numbers (using the above dictionary as much as possible to avoid having hard-coded country-specific rules)