SMS - Hide Carrier Selection Preference

[Josh Stompro]

When using an SMS reactor that doesn't require a carrier (bug #1667080) for sending SMS hold pickup messages the opac.default_sms_carrier user pref needs to be not shown to avoid gathering info that isn't needed.

I think that adding a new library setting that will go along with the current 'sms.enable' would be a reasonable way to do this. 'sms.hide_carrier'.

Besides adding a check for that pref to a few forms, I think that the hold/sms validation code might need to be adjusted. Bug 1098685.

Josh

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

I started looking at this and found that right now an SMS carrier is required to place a hold due to a DB consistency check. If sms_phone is not null then sms_carrier must be not null.

So I'm wondering if I should go down the route of relaxing that consistency check, or should I just pick a carrier id and send that with the hold to minimize the scope of the change.

Here is what I have so far that either uses the default_carrier or picks the first one in the hash.

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

Josh

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

Hmm, how do we handle changing pickup locations between a location that needs sms_carrier and one that doesn't. Or rather between a location that doesn't require sms_carrier and one that does. I guess the trigger could re-enter the default sms_carrier setting if switching, otherwize just remove sms_notify for that hold. Switching pickup lib does happen, but usually by accident and not very often in my experience.

Right now I'm thinking that it might be easier to replace the consistency check with a trigger that just removes the sms_phone if an update changes the pickup lib to a pickup_lib that doesn't support sms.hide_carrier.

But then I guess showing/hiding the sms_carrier field would need to be done based on the pickup location drop down and not the current search lib.

In our case no one in our consortium will still be using the email->sms method, so no one needs it, but that most likely won't be the case for everyone.

Josh