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
[email protected] <mailto:[email protected]>
On Thu, Apr 20, 2017 at 10:36 AM, Blake Henderson
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
On Thu, Apr 20, 2017 at 9:40 AM, Terran McCanna
<[email protected]
<mailto:[email protected]>> 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 <tel:%28404%29%20235-7138>
[email protected]
<mailto:[email protected]>
On Wed, Apr 19, 2017 at 9:53 PM, Blake Henderson
<[email protected]
<mailto:[email protected]>> 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
