Bug 14611 - SMS::Send hangs on malformed mobile #, process_message_queue fails
Summary: SMS::Send hangs on malformed mobile #, process_message_queue fails
Status: RESOLVED DUPLICATE of bug 3186
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: unspecified
Hardware: All All
: P2 critical (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-28 20:27 UTC by Fred P
Modified: 2015-08-19 15:17 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred P 2015-07-28 20:27:35 UTC
SMS::Send hangs on malformed mobile #, process_message_queue fails

Staff entered an e-mail address into the mobile phone field - the software fails to test the input for numeric, just records the e-mail address as a string. SMS::Send from PERL balks at processing the malformed string as a phone number and the message queue cannot send the remaining messages, leaving them all marked as pending. Eliminating the problem message from the message_queue allows the messages to send (all the back messages as well), but the problem reoccurs the next time that patron is text messaged.

Again, this is when text information is entered into the mobile phone number field for a patron that specifies an SMS transport type.
Comment 1 Kyle M Hall 2015-07-30 14:50:12 UTC
I'm not sure if there is a simple universal solutions to this considering the differing  phone number formats there are internationally. Would simply changing the sms number to int and stripping out all non-numeric characters be a practical solution, or is that too limiting?
Comment 2 Fred P 2015-07-30 15:53:27 UTC
I guess the question boils down to how we prevent human error in the data entry, and the method we select may not be foolproof. It's a bit complicated, but we could regex-verify the string, allowing for numerics, plusses, parentheses and hyphens - that would catch most of the errors. I'm not sure that would prevent 100% of SMS::Send crashes, but it might. Basically we would strip out unwanted characters on entry (or request a new entry) and hope SMS::Send can properly handle "phone" characters. The documentation suggests that plusses, parentheses and hyphens are not a problem, although I have not tested for situations like ((330)) 678--5497

Converting our string to a numeric integer is another possibility, but parsing that for visual display might be difficult, due to different global formulas. Library staff don't want to look at ten or eleven numbers without hyphenation. One way to implement a numeric conversion would be to keep the string saved, and create a new field for the numeric - so you would have both. Adding fields to the database is not the ideal solution though.

Google provides a library for testing and parsing phone numbers:
https://github.com/googlei18n/libphonenumber

This regex test might work, although many methods are possible with regex:
/^(?:(?:\(?(?:00|\+)([1-4]\d\d|[1-9]\d?)\)?)?[\-\.\ \\\/]?)?((?:\(?\d{1,}\)?[\-\.\ \\\/]?){0,})(?:[\-\.\ \\\/]?(?:#|ext\.?|extension|x)[\-\.\ \\\/]?(\d+))?$/i
Comment 3 Kyle M Hall 2015-08-04 14:19:26 UTC
Excellent writeup!

It seems to me that checking on the front-end using libphonenumber would be the simplest and most effect change. Of course this doesn't fix bad phone numbers already in the database. I think updatedatabase could do a basic validity check and warn if there is anything untoward in there.
Comment 4 Fred P 2015-08-04 19:23:39 UTC
Kyle - I think the patch you approved for Bug 3186 might cover our situation. I thought I had it installed already, but the timing was such that we did not get it yet. The following patch should resolve the process_message_queue failure, in which case this is a duplicate bug:

http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31291

Although using the Google-supplied library to test phone numbers would help catch data-entry errors. Thanks!
Comment 5 Jonathan Druart 2015-08-19 15:17:51 UTC

*** This bug has been marked as a duplicate of bug 3186 ***