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.
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?
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
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.
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!
*** This bug has been marked as a duplicate of bug 3186 ***