Strip Punctuation and Spaces from SMS numbers when entered in the OPAC

[Jason Stephenson]

Rather than warn the user how NOT to enter the SMS number for SMS notifications with the following text, "Hint: use the full 10 digits of your phone #, no spaces, no dashes," EGWeb ought to just strip out any space or punctuation characters from the SMS number field after it is submitted.

[Jason Stephenson (jstephenson)]

Working branch in user/dyrcona/lp1830065-clean-sms-notify:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1830065-clean-sms-notify

It's literally a one line change.

[Jason Stephenson (jstephenson)]

Removing the pullrequest tag after taking a closer look at our actual data. We have home "punctation" characters that my current implementation does not catch. I'm likely to change the branch to strip out all non-digit characters.

I also want to check how much of an issue this really is. I jumped in and made this bug report and branch with only 1 reported case of someone's notification not working.

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

We have seen bad data being entered all the time, we have a nightly check that looks for various issues and sms phone numbers that don't meet the correct format. I'm in favor of adding more validation up front.

[Jeff Godin (jgodin)]

We store phone numbers as 999-999-9999.

Is the issue here that those using email to SMS gateways require the number to be digits-only?

Rather than store phone numbers using two different conventions, would it be better to strip undesired characters during the A/T phase?

I think that displaying phone numbers to staff or patrons as 9999999999 may not be helpful.

[tangent for another bug: storing phone numbers in their own table as E.164 normalized values and converting to something locale-specific for display/entry purposes in a way similar to how we handle dates]

[Jason Stephenson (jstephenson)]

The A/T phase already strips -, <space>, (, and ). <space> is a literal space character. You can see this at line 397 of Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/Rector.pm in master.

I proposed [:space:] and [:punct:]. However, using the latter might be overkill because you can set up aliases for Email -> SMS gateways with some providers. I know that Thomas Berezansky of MVLC had this setup for his account.

I was about to mark this bug as invalid, but I'm going to set it back to New so we can have some discussion on what extra validation should be done, if anyone.

I have verified that the notification that triggered my making this bug was indeed sent to, and accepted by, our email provider. What happened after that, I can't say. This is another case of me jumping the gun again.

The only characters that I see in our database that will possibly break for our users are Unicode smart quotes. Soem of our staff seem to have entered notes in these fields on some patron's accounts but they basically say that no call is necessary. I have not, yet, looked to see what these look like in the A/T tables or email logs.

[Lugene Shelly (lugene)]

This has caused some confusion for SPARK libraries when registering patrons. In the Patron Registration Screen, the instructions provided in the OPAC are missing for staff. We've heard from staff members that adding hyphens, spaces or other symbols in the Default SMS/Text Number field during registration will cause the text to bounce.