Attempt to write a +229 xx xx xx xx xx (10 digit) phone number which is the STANDARD in Benin since 2024 fails. "Phone number too long." intl-tel-input appears to be woefully out of date. Upgraded to 10.0.11 from 10.0.9. Issue persists. How can we fix this quickly? We need to input data asap.
-
-
Temporary disable international phone numbers at: Administration > Settings. Enable back once it is fixed in a future version. -
Interesting thing is, I noticed on an existing Contact that has a Benin number, they HAVE a +229 10 digit number stored. It appears to happen when converting from a Lead to a Contact. In working with an AI on the issue, what I've asked for clarity and had answered is this:
The core files causing the issue are /var/www/html/client/lib/espo.js and /var/www/html/client/lib/espo-main.js.
These compiled distribution files bundle the frontend intl-tel-input library, which statically hardcodes the outdated 8-digit Benin regex pattern and length constraints instead of referencing the updated PHP metadata.
[which files are updated and already allow 10 character for Benin?]
/var/www/html/vendor/giggsey/libphonenumber-for-php/src/data/PhoneNumberMetadata_BJ.php (and the underlying brick/phonenumber data files).
These backend PHP files already contain the updated 10-digit Benin rules, which is why your PHP script tests passed while the frontend UI blocked the input.
We have a lot of data to move from Leads and don't want to possibly end up with incorrect data. Are there any steps I can take to bypass this behavior currently/locally until it is fixed?
Thank you.Comment
-
The frontend phone number library introduces breaking changes in every release, we need to bump 11 versions up, each one with breaking changes. It's a nightmare for maintaners. We will try to update the library for the next minor release but no guarantees.
I can't help with any fix. I don't know how to fix without updating the lib or turning off the feature as I described above.Comment
Comment