Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Continuing the discussion from #2791905: Consolidate features with SMS Framework.
After going over the code, I could not find where a phone number's verification status is used apart from SMS Blast which sends SMS only to verified numbers. But verification is not required and is not explained why it is needed, so I do not see why a user would choose to verify their number.
If verification is used by a submodule for a single purpose, it begs the question why the verification system is in SMS Framework's core.
Plus, a site owner may want to be able to send SMS to unverified numbers. For example, if phone numbers were imported from another database that does not track verification status.
Comments
Comment #2
nyariv CreditAttribution: nyariv commentedThe question is, how important is it for SmsF to maintain a verification system?
Sms blast is a very specific use case, it would make more sense to integrate with VBO and let the user filter who to send to in bulk, which would simplify some of the current implementation, and allow to filter by verified numbers if implemented by a 3rd party module.
I noticed also Sms_sendtophone relies on sender number being verified, but you cannot customize sender information for sms in the US and other countries and it is not possible with gateways such as clickatell. And a more appropriate name for the module would be "sms share", since you are sending a predefined message to any number. Also the number field could use Mobile Number's form element which would validate the number before submitting and help with adding country prefix which many users don't know is needed.
And while we are at it, sms_user is also a very specific use case. I am wondering what were the original maintainer's thoughts that he thought user creation by sms is a needed feature. (2007 thinking?)
Comment #3
dpiThe main entry point is phonenumberprovider->sendMessage, allowing code to send messages to entities, rather than phone numbers.
The purpose is to prevent code from sending to phone numbers that are unconfirmed, that is, opt in to messages.
It also allows users to opt out of messages, but keep the verification.
The entity also keeps track of active hours, so if a message is sent to a user, the code can determine for example if he is asleep or outside legislated permitted hours.
A single purpose is enough.
The feature is a remnant of older versions, and seems like a feature that could still be desired.
Even if we dont have any internal usages, if it is an important and widely desired feature it makes sense to integrate it. So long as there is plenty of test coverage.
See second param of
phonenumberprovider->getPhoneNumbers.This param could have been on
sendMessage. But personally Id rather you jump through one more hoop than be able to easily force your messages through to unverified numbers.Create a different issue if its unrelated. If you want a Q&A then you can find me in IRC.
I pretty much rewrote the entire module in #2643692: SMS User Redesign.
Verification moved to main module as a service, active hours and incoming account creation are the features remaining.
Active hours is even implemented on a gateway API level (MailUp, as an example), so I assume its being used. We can make it more intelligent on the Drupal level because we have access to specific recipient local time.
Comment #4
dpi