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

Bug #1830065 reported by Jason Stephenson on 2019-05-22
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

Changed in evergreen:
status: New → Confirmed
tags: added: patron
Jason Stephenson (jstephenson) wrote :

Working branch in user/dyrcona/lp1830065-clean-sms-notify:;a=shortlog;h=refs/heads/user/dyrcona/lp1830065-clean-sms-notify

It's literally a one line change.

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
milestone: none → 3.4-beta1
tags: added: pullrequest
removed: patron
Jason Stephenson (jstephenson) wrote :

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.

tags: removed: pullrequest

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) wrote :

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) wrote :

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/ 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.

Changed in evergreen:
status: Confirmed → New
tags: added: needsdiscussion
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers