thatbudakguy
commented
6 years ago Hi @cgb37 ;
this plugin is an attempt to create basic SMS functionality by hijacking Primo's sendEmailService to email an item record to a free carrier SMS gateway, which converts the email to a text message. As such:
- implementation is highly dependent on how the carrier runs their gateway. not every carrier operates a free gateway and the various ones have different limitations.
- we have almost no control over what is sent, because the Primo send email API accepts only an item record and generates the email text on the backend.
We are effectively forcing Primo to "email me this item", except that email is sent to a service that converts the email to a text message. That's about all there is to it.
The docs you've linked seem to be about plugging Primo into an account one would already have open with a paid SMS provider, which would be an alternative to the free carrier-run SMS gateways. That would give you a lot more power, but it's outside the scope of this plugin.
It seems as if different carriers handle the text messages differently. We've had a lot of complaints about super long messages with useless info or no call numbers. How can we specify what information to send?
The Primo docs https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/Technical_Guide/130Sending_SMS_Messages say the following items are sent:
title: at least 20 characters of the title are included. If there is no space for the complete title, then the title will end with an ellipsis (…). ispartof (citation for articles): the entire field is included even if this means sending more than one SMS message. availlibrary (availability): there can be several lines. Preference is given to the lines that match the institution of the user and that are "Available" ($$Savailable); second priority should be given to Check-Holdings ($$Scheck_holdings). The following subfields from availlibrary will be sent: $$L library name $$1 sublocation $$2 call-number