action_trigger - support immediate event processing

Bug #1745216 reported by Josh Stompro
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Invalid
Undecided
Unassigned

Bug Description

Hello, while discussing a possible new feature of having a way for staff to fire off test messages to customers to test their notification settings, it was brought up that it would be nice if the test message happened as close to instantly as possible.

http://masslnc.org/node/3154#comment-2154

I think that the feature would use the action_trigger system to send the test messages. Which uses cron to run action_trigger_runner.pl at regular intervals. The minimum cron run time is every minute. Which would add a delay between 0 and 60 seconds before the events are processed and test notifications sent.

If a customer is standing in front of you, or is on the phone with you, it would be nice for the test messages to happen quickly consistently to save staff time and customer time.

Another use case would be for the customer welcome emails to get sent off as soon as a new patron record is created, so any bounce backs get to staff asap, so staff can talk to the customer immediately about why their email didn't work.

And yet one more use case is for the password reset emails. It would be good customer service to get those sent asap so that the reset message is in the customers inbox as soon as they go from the catalog login form to their email.

One method of making this happen may be to use the postgres listen/notify feature which allows one process to listen for an event notification fired off by another process. There could be a trigger setup on action_trigger.event that runs notify command whenever a new row is added, or when the add_time changes for a row. It could just always send the granularity value as the channel. Then there could be another process on the utility server that uses listen to look for new events for whatever granularity is wanted, and then fire off action_trigger_runner.pl for that event. Once action_trigger_runner.pl returns, check for missed events that came in while executing, then go back to waiting for a new event.

Postgres LISTEN docs - https://www.postgresql.org/docs/9.4/static/sql-listen.html
Postgres NOTIFY docs - https://www.postgresql.org/docs/9.4/static/sql-notify.html
Perl script example for waiting for events - https://<email address hidden>
More examples and discussion - https://omniti.com/seeds/stop-collaborate-and-listen-notify

Revision history for this message
Joan Kranich (jkranich) wrote :

I agree with a more immediate response from the action triggers for password resets and other uses of notifying the patron or staff.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

This ticket can be closed, there is a way to handle this already. The Email test and SMS test features in the patron edit screen make use of the method to create and trigger events instantly.

See Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm (Sub fire_test_notification) for an example.

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;hb=a587c50be44177f1d947447ab23f5aee9c379e75#l4541

Every application server needs to be setup to send any outgoing notifications that are needed in this case, which was confusing to me since we had always sent everything from our Utility server, but it works well once it is setup correctly for that.

Andrea Neiman (aneiman)
Changed in evergreen:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.