[Eg-newdevs] Action trigger for Hemlock push notifications

Fri Jan 17 18:29:02 EST 2025

Dan,

I did stay interested for the whole video, and I found it quite
informative.  Thank you!  I am persuaded by your investigation and
arguments that:

a) using hemlock.push_notification_data as the Opt-In Setting Type is not
working as intended because it is a string, and
b) the simplest and thus the best solution is for the Hemlock app to store
two user settings:

hemlock.push_notification_data - the push notification token itself

hemlock.push_notification_enabled - boolean true when we have a push
notification token

I think in the near future we may want a timestamp as well.  Sadly this
means a third user setting type, because the actor.usr_setting table does
not include a timestamp:

hemlock.push_notification_ts - timestamp when
hemlock.push_notification_data was last modified

According to Best practices for FCM registration token management
<https://firebase.google.com/docs/cloud-messaging/manage-tokens>, if an FCM
token becomes stale, we should stop trying to use it. Currently, the
Hemlock app only writes the token (via
open-ils.actor.patron.settings.update) when it is different from what it
fetched.  We don't want to rewrite it on every launch.  I don't have all
the moving parts worked out yet, but I think we have to rely on Evergreen
to detect "staleness", because we can't be guaranteed the app will ever run
again on that device.  But if Evergreen is detecting stale tokens and
deleting them (or setting hemlock.push_notification_enabled to false), then
the app needs to run periodically in order to refresh the token, and there
could be windows where it is possible to miss notifications.

Gina -- if you agree (on adding an "enabled" setting for now), please go
ahead and add it and I can update the app to set it to true.  Or we can
discuss further in chat or at the next "new devs" meeting.

Ken

On Fri, Jan 17, 2025 at 2:05 PM Dan Briem via Eg-newdevs <
eg-newdevs at list.evergreen-ils.org> wrote:

> 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>
> _______________________________________________
> Eg-newdevs mailing list
> Eg-newdevs at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs
>

-- 
-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-newdevs/attachments/20250117/815239bc/attachment-0001.htm>