[Eg-newdevs] Action trigger for Hemlock push notifications

Sat Jan 18 12:22:56 EST 2025

Once all of these pieces are worked out, we can also discuss packaging the
settings, a couple of example action triggers, and other changes up into a
branch to submit to core Evergreen so that future libraries that decide to
implement it will have fewer steps.

On Fri, Jan 17, 2025, 6:29 PM Ken Cox via Eg-newdevs <
eg-newdevs at list.evergreen-ils.org> wrote:

> 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
>> <https://www.google.com/maps/search/2+Bruce+Ave.+Harrison,+NY+10528?entry=gmail&source=g>
>> (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
> _______________________________________________
> Eg-newdevs mailing list
> Eg-newdevs at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-newdevs/attachments/20250118/a1bd3b9a/attachment.htm>