[OPEN-ILS-DEV] usr message center and sms_notify grouping

[Terran McCanna]

Do you have a Trigger Event Parameter set up for check_sms_notify = 1?

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmccanna at georgialibraries.org


On Thu, Apr 20, 2017 at 10:36 AM, Blake Henderson <
blake at mobiusconsortium.org> wrote:

> We do have the message path set. These action triggers were all originally
> setup to deliver the SMS text. We simply copied the template column over to
> the message_template, thereby "piggy backing" the message center component
> on existing action triggers. Instead of creating new action triggers just
> for the message center. This seems to be working, where the action trigger
> would send the text/email AND place a message in the message center.
>
> The problem is when the group_field='sms_notify'  and ahr.sms_notify is
> null.
>
> In my opinion, the code should ignore null values in the column defined by
> group_field.
>
> -Blake-
> Conducting Magic
> MOBIUS
>
> On 4/20/2017 8:59 AM, Morgan, Michele wrote:
>
> Blake,
>
> Another thought. Do you have the Message User Path set in the trigger
> definition?
>
> We have not added message center messages for circulation or hold type
> notices, but have done this for the soon to expire patron notices.
>
> -Michele
>
> --
> Michele M. Morgan, Technical Support Analyst
> North of Boston Library Exchange, Danvers Massachusetts
> mmorgan at noblenet.org
>
>
> On Thu, Apr 20, 2017 at 9:40 AM, Terran McCanna <
> tmccanna at georgialibraries.org> wrote:
>
>> Hi Blake,
>>
>> We began doing PMC notices along with SMS and Email in January, and we
>> haven't seen that problem. Are all of your message types showing all the
>> holds, or just one of the message types?
>>
>> Do you have a separate action trigger for each type of notification? (We
>> use one for email, one for pmc, one for sms.)
>>
>> Most types of message triggers should have the Processing Group Context
>> Field set to usr. The only one of our SMS notices that has it set to
>> sms_notify is the the Hold Ready for Pickup SMS Notification and I'm
>> honestly not sure why that one is different. That one also has an Event
>> Parameters setting where check_sms_notify is set to 1 - perhaps because it
>> has an opt-in flag in the patron settings to check, and the other types of
>> SMS messages don't have an equivalent opt-in flag?
>>
>> Terran McCanna
>> PINES Program Manager
>> Georgia Public Library Service
>> 1800 Century Place, Suite 150
>> Atlanta, GA 30345
>> 404-235-7138 <%28404%29%20235-7138>
>> tmccanna at georgialibraries.org
>>
>>
>> On Wed, Apr 19, 2017 at 9:53 PM, Blake Henderson <
>> blake at mobiusconsortium.org> wrote:
>>
>>> All,
>>>
>>> Something interesting. Recently, we decided that all of our SendSMS and
>>> SendEmail triggers need to also have a copy of the message in the message
>>> center. This helps our library staff see the messages that the server
>>> attempts to deliver easily. After making this change, I am finding messages
>>> for a patron that contains a list of all of the holds available for pickup
>>> for EVERYONE at that branch. Luckily there isn't any identifying
>>> information.
>>>
>>> After some digging, I am finding that it's due to the hold having a null
>>> value for sms_notify, which happens to be the group_field for the action
>>> trigger. If I remove the grouping, then patrons with the same SMS phone
>>> number will receive a separate text for each item ready for pickup which
>>> would be annoying.
>>>
>>> This helps me find the definitions:
>>>
>>> select * from action_trigger.event_definition where (message_template
>>> is not null or length(message_template)>1)
>>> and
>>> (group_field is not null and group_field !='usr')
>>>
>>>
>>> So, is this a bug? Any ideas or advice?
>>>
>>>
>>> --
>>> -Blake-
>>> Conducting Magic
>>> MOBIUS
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20170420/9d5dfc3a/attachment.html>