Email-to-SMS Gateway No Longer Supported by Some Carriers

[Jennifer Pringle]

Evergreen 3.9

We're finding that more and more carriers either don't provide the information needed to set them up as a carrier in Evergreen or are no longer supporting email to SMS at all. If this trend continues we'll need to look at other options for Evergreen for messages by text.

This also affects potential implementation of multi-factor authentication as SMS isn't currently a reliable option.

[Terran McCanna (tmccanna)]

We're also seeing this trend. The ability to send a "real" text rather than an SMS text would improve the situation.

[Josh Stompro (u-launchpad-stompro-org)]

Check out bug #1667080 for what we use to send sms notices with a vendor via an API. We have used it since 2018 after having trouble with the sms gateways back then.

I haven't full dealt with the issue of no longer needing the sms_carrier data. It is still required to be set to place a hold since there is a database requirement that it be non null if the sms_phone is set when placing a hold. Right now I've changed the carrier html form fields to always have a default value and to be hidden by default.

Dealing with a mixed environment with some branches using a vendor and some using the gateway will be interesting.

[Jason Stephenson (jstephenson)]

Database constraints can always be changed. We've done crazier things in upgrade scripts before.

My main concern is that the SMS solutions that "always" work all cost money. I have mixed feelings about adding them to Evergreen. I could accept a situation where we've added multiple vendors as optional add-ons that a site can choose to activate. This might require a compatibility module on top. I fear that adding one and not some of the others will look like an endorsement from the community.

The default should always remain the free (as in beer) option in my opinion.