TPAC: System should disallow patrons from entering SMS number in wrong format

[Kathy Lussier]

Evergreen version: 2.2 RC1

Wishlist item

Despite the hint telling users not to use hyphens when entering an text notify number, we have patrons who are entering the hyphens. The text notice subsequently fails. We would like some kind of check to prevent the user from entering the number in the wrong format.

[Thomas Berezansky (tsbere)]

The only way I could see implementing this is as a per-service regex. Even then I would be wary of being too strict with it.

For example, I could, in theory, use my "nickname" instead of my cell number and provided that it was stuck in front of the correct @domain I would get a text message.

[Kathy Lussier (klussier)]

I could see where using a nickname would be convenient for some power users, but I suspect there are fewer users looking to use a nickname than there are users who will overlook the hint and enter their SMS number in a format that will fail.

Giving it further thought, I suppose there are a couple of approaches that could be taken:

1. If the patron enters the SMS number in the wrong format, the system returns an error asking them to enter it in the correct format.

2. If the patron enters the SMS number in the wrong format, the system automatically removes any hyphens in the number (much more user friendly than option 1).

3. The text entry box only allows the patron to enter 10 characters. Once the patron notices that they aren't able to complete the entry, they re-read the screen and see what the correct format should be (or complain to their local library staff that the form doesn't work.)

4. The form provides three boxes, one for area code (limited to 3 characters), one for local exchange (limited to 3 characters), and one for the number (limited to 4 characters.) The system then takes these entries and enters it as one SMS number.

However, I don't think any of these options would allow patrons to use a nickname.

[Michael Peters (mrpeters)]

We've had a couple of complaints about this not "validating" like "the other phone fields" do since upgrading to 2.2. I guess people just don't see the hint. I tend to side with Kathy on this. We're more likely for people to use their phone number than some kind of alias, but I'm sure we can come up with some kind of compromise that makes things work for (nearly) everyone.

[Thomas Berezansky (tsbere)]

On the front of the listed options in comment #2:

#1 would work for per-service regex type deals fairly easily.

#2 could apply as well, but I still think a per-service config is needed, if only to validate that the correct number of digits was provided.

#3 and #4 are not portable outside of NANP numbers and I thus disagree with. We can't assume that Evergreen will only ever be used in the US and Canada type deal.

[Michael Peters (mrpeters)]

If someone whips up an internal solution to this, I'd enjoy seeing it. I'm comfortable saying Evergreen Indiana will never get used by someone with one of these non-US/Canada exceptions and willing to risk that in order to gain more reliable service for patrons who don't see the helper.

[Michael Peters (mrpeters)]

Thanks to Bill Ott for some working code:

http://git.evergreen.lib.in.us/git/?p=Evergreen.INCustom/Evergreen/.git;a=commitdiff;h=38198c03e5ea10a98ac24d63fca1af75e1b34cfd

[Thomas Berezansky (tsbere)]

I believe something more robust (aka, server-side) is needed as we shouldn't be relying on JavaScript for input validation. Well, inside the staff client where we know it is turned on perhaps, but relying on it outside of the staff client seems problematic.

[Michael Peters (mrpeters)]

Maybe this should become a Wishlist item, then. This, at least, gets a working solution in place in the short term if anyone happens upon this thread. Yes, it can be modified to "break the script rules" but at least for 99% of the users it's just an enhancement to the usability of the field. Of course, it could be expanded (change colors on invalid input, pop up a message, etc.) but this is a quick and easy short term solution.

[Thomas Berezansky (tsbere)]

An alternative to client-side munging:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/sms_munge

That branch says "If it looks to be all digits, spaces, hyphens, and parentheses then strip it down to just digits. Otherwise assume that it is some kind of alias the service supports". It applies at the A/T layer and thus requires no DB updates, and makes no assumptions about lengths of numbers.

[Michael Peters (mrpeters)]

Sign off on the sms_munge branch. Works well.
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=2ca368779b875561eb68a7016115e3b2d3a19148

I'll also toss out user/mrpeters-isl/sms_helper which updates the helpers.
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=521cb69a255f5cddc70b9af83b5ab83bbc221b9b

[Ben Shum (bshum)]

Picked fix to master and rel_2_3. SMS being broken seemed more like a bug than a brand new feature to me.

The wording contained in the sms_helper commit was MIA from the link indicated, but I checked the working repo for it.

I'm not sure how to handle translation effects on the entry. Firstly, we probably shouldn't alter it in 2.3 anymore, but for master we could. Though should the two sentences be broken up separately translated? Or as that single line? And do we really have to update the POs or does that happen elsewhere in the process? Hmm...

[Ben Shum (bshum)]

Oh, for those who go to look, this is the working branch that mrpeters started for updating the helper text:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrpeters-isl/sms_helper