[Eg-newdevs] Action trigger for Hemlock push notifications

[Dan Briem]

I tested the action trigger with the opt-in feature and a custom filter
(recording here: https://youtu.be/n--asMO61g8).

Granted, I haven't been at the meetings, so hopefully I didn't
misunderstand what we were trying to do (or how the Hemlock setting works).

The opt-in setting feature didn't work for me because I used a string (I'm
assuming it is) and Evergreen checks for a "true" boolean value. When I ran
it as a custom filter, it worked.

As an alternative, maybe Hemlock can create another user setting that's a
boolean in addition to the token so we can use the opt-in setting feature
instead? This would be good for active hooks, like hold.available. Or,
maybe on the Evergreen side, the opt-in setting feature could be expanded
to include conditions or something like that (not sure if that's the way to
go, though).

On Thu, Jan 16, 2025 at 10:52 AM Gina Monti via Eg-newdevs <
eg-newdevs at list.evergreen-ils.org> wrote:

> Thanks so much, Michele!  I'll give this a shot and will report back.
>
> On Thu, Jan 16, 2025 at 10:13 AM Morgan, Michele <mmorgan at noblenet.org>
> wrote:
>
>> After Gina shared their experiences with setting up a Hemlock push
>> notifications action trigger at the meeting yesterday, I wondered again
>> about using the opt-in functionality built into the action triggers to
>> limit which patrons receive the notifications, rather than a custom filter.
>> We have several action triggers running successfully in production using
>> user settings to allow patrons to opt-in to certain notices, so I wasn't
>> sure what would be different with this one.
>>
>> I took a little time to try setting one up on one of our test systems
>> using the user setting type in the '*Opt-in Setting Type*' field in the
>> event definition. Long story short, it worked for me! No custom filter was
>> necessary, and events were only created for the patron with the user
>> setting set.
>>
>> To set up the definition, I cloned one of our existing overdue
>> notification triggers, saying *Yes to cloning the Environment.* Then I
>> edited the definition to use the Hemlock push notifications user setting.
>>
>> These are the fields from the event definition that worked:
>>
>> Owning Library: NOBLE *(Consortium)*
>> Name: Hemlock push notifications
>> Hook: checkout.due
>> Enabled: true
>> Processing Delay: 1 day
>> Processing Delay Context Field: due_date
>> Processing Group Context Field: usr
>> Reactor: *ProcessTemplate* *(for testing, so the event_output will be
>> generated, but nothing else will happen. For production, this would be
>> CallHTTP)*
>> Validator: CircIsOpen
>> Event Repeatability Delay: *00:01:00* *(for testing, allowing duplicate
>> events to be created after 1 minute for subsequent runs of the trigger)*
>> Granularity: *hemlock_push* *(for testing: to control when the trigger
>> runs, can be used for production as well)*
>> Max Event Validity Delay: 10 days
>> Opt-In Setting Type: *hemlock.push_notification_data*
>> Opt-In User Field: *usr*
>> Retention Interval: 6 mons
>> *Template:* *(from Ken's
>> documentation: https://github.com/kenstir/hemlock-docs/blob/main/docs/pn-setup-guide/configure-evergreen.md#sample-template
>> <https://github.com/kenstir/hemlock-docs/blob/main/docs/pn-setup-guide/configure-evergreen.md#sample-template>)*
>> Context Bib Path: target_copy.call_number.record
>> Context Item Path: target_copy
>> Context Library Path: circ_lib
>> Context User Path: usr
>>
>> This command will run only this trigger based on its granularity:
>>
>> /openils/bin/action_trigger_runner.pl --osrf-config
>> /openils/conf/opensrf_core.xml --process-hooks --run-pending --granularity
>> hemlock_push --granularity-only
>>
>> Running this trigger will look at circulations due between one day and
>> ten days ago. On my test system, there are seven open circulations due in
>> this time period. I set the user setting hemlock.push_notification_data for
>> one user linked to two of those checkouts. Only two events were created,
>> linked to one row that was created in event_output.
>>
>> I removed the user setting from the patron and ran the trigger again
>> after one minute. No events were created. Here is the log entry showing the
>> criteria for gathering the circs:
>>
>> [2025-01-16 14:35:46] open-ils.trigger
>> [INFO:307910:CStoreEditor.pm:155:173703694530637333] editor[1|0] request
>> en-US open-ils.cstore.direct.action.circulation.id_list.atomic
>> [{"checkin_time":null,"-and":[{"+atev":{"id":null}},
>> *{"-exists":{"from":"aus","where":{"name":"hemlock.push_notification_data","value":"true","usr":{"=":{"+circ":"usr"}}}}}*],"due_date":{"between":["2025-01-06
>> 14:35:46+0000","2025-01-15
>> 14:35:46+0000"]},"circ_lib":{"in":{"where":{"id":1},"select":{"aou":[{"transform":"actor.org_unit_descendants","column":"id","result_field":"id"}]},"from":"aou"}},"-or":[{"stop_fines":["MAXFINES"]},{"stop_fines":null}]},{"join":{"atev":{"type":"left","fkey":"id","filter":{"event_def":585,"start_time":{">":"2025-01-16
>> 14:34:46+0000"}},"field":"target"}}}]
>>
>> So the opt-in setting should definitely work to limit events to patrons
>> with the setting, there should be no need for a custom filter.
>>
>> I hope this is helpful! We're definitely interested in this feature also!
>>
>> Michele
>>
>> --
>> Michele M. Morgan, Systems Support Specialist
>> North of Boston Library Exchange, Danvers Massachusetts
>> mmorgan at noblenet.org
>>
>>
>
> --
>
> Gina Monti (she/her)
> Evergreen Systems Manager
> Bibliomation, Inc.
> (203) 577-4070 ext. 109
> English, American Sign Language
> _______________________________________________
> Eg-newdevs mailing list
> Eg-newdevs at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs
>


-- 
Dan Briem
Harrison Public Library
2 Bruce Ave. Harrison, NY 10528
(914) 835-0324
harrisonpl.org <https://www.harrisonpl.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-newdevs/attachments/20250117/df0dc281/attachment.htm>