E164 validator project

[dpi]

Ideas and brainstorming for a new E164 validator project.

Separate project to sms framework

Problem

Currently SMS Framework will accept any string for use as a phone number. This behaviour is fine, however, some gateways may want to ensure they only receive a valid E164.

Technical

• Drupal dependencies: This module would only depend on core SMS Framework.
• Composer dependencies: Project would depends on libphonenumber
• Gateway dependency: gateways wishing to opt in to this functionality would need to depend on this new project at a module level.
• Gateway plugin: Gateways requiring this feature would specify in a new requires_e164 or similar gateway annotation. The annotation would be boolean. TRUE to opt in. Missing annotation value would fall back to FALSE.

Module operation

In the processing phase of an outgoing message, the validator will attempt to coerce the phone number into E164. Local phone numbers will attempt to be transformed into international E164 using site level, and if available target entity,

Fail to convert to E164

Failure to convert a phone number to E164 would remove candidate gateways for the message which require E164.

Why separate module

SMS Framework does not require Composer. This module would require it.

This module would be pretty slim, mainly using functions from libphonenumber, and using SMS Framework API's/events to bind everything together

There may be some kind of global fallback country configuration for users. But I imagine we would have an option to probe for a users country/timezone based on its preferences/attached field values.

Related

• Utilize LibPhonenumber for phone number validation