Telephone number validation #29599
Comments
|
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 ? |
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 ? |
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
entitycolumn 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.sqlkey:
data:
dictionary declaration
[ 'tabname' => 'c_calling_code', 'tablib' => 'CallingCode', 'tabsql' => 'SELECT cc.rowid, c.label AS country, cc.isd_code FROM '.$db->prefix().'c_calling_code AS cc' .' INNER JOIN '.$db->prefix().'c_country AS c ON cc.fk_c_country = c.rowid', 'tabsqlsort' => 'c.label ASC', 'tabfield' => 'country,isd_code', 'tabfieldvalue' => 'country,isd_code', 'tabfieldinsert' => 'fk_c_country,isd_code', 'tabrowid' => 'rowid', 'tabcond' => '($conf->financement->enabled) ?? 0 && ($conf->clihlf->enabled ?? 0)' ],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)The text was updated successfully, but these errors were encountered: