I'm not entirely sure what the event parameter does but we have it set on ours - as far as I know, it was set that way by default when it was originally implemented (before my time). We also have our PMC split out because the documentation for it says that it should be separate: http://docs.evergreen-ils.org/dev/_patron_message_center.html
Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org On Thu, Apr 20, 2017 at 11:23 AM, Blake Henderson < bl...@mobiusconsortium.org> wrote: > Terran, > > These event definitions do not have any parameters set. They do have 3 > environment vars: > > "current_copy.call_number.record.simple_record" > "usr" > "pickup_lib.billing_address" > > > if check_sms_notify = 1 was setup, will the Evergreen code check > actor.usr_setting (column name setting="opac.default_sms_notify") ? > > If that is the case, I don't think the problem will be avoided, because > it's still possible for ahr to have a null value in sms_notify > > -Blake- > Conducting Magic > MOBIUS > > On 4/20/2017 10:07 AM, Terran McCanna wrote: > > 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 <(404)%20235-7138> > tmcca...@georgialibraries.org > > > On Thu, Apr 20, 2017 at 10:36 AM, Blake Henderson < > bl...@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 >> mmor...@noblenet.org >> >> >> On Thu, Apr 20, 2017 at 9:40 AM, Terran McCanna < >> tmcca...@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> >>> tmcca...@georgialibraries.org >>> >>> >>> On Wed, Apr 19, 2017 at 9:53 PM, Blake Henderson < >>> bl...@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 >>>> >>>> >>> >> >> > >
