Bill Erickson wrote:
Hi all,
I put some thoughts together on how we may want to wire up the
plumbing for event-based notifications.
http://open-ils.org/dokuwiki/doku.php?id=feature:notifications
There are missing pieces, questions, and likely some non-obvious
assumptions on my part, but I wanted to push it out to solicit
thoughts on filling in the gaps or doing things differently. The code
will probably be developed in stages, starting with email notices and
only a few event types, later moving on to telephony, etc. Anyway,
let me know if you have any thoughts or questions.
Thanks,
-b
Bill,
I was just taking a look at your document for notification internals,
and I have a few questions. Your message is from 11/9/08 so let me know
if this has been supplanted by something else.
Under creating notices you say Context information is passed directly
to a new class method OpenILS::Notify→create_notification($user_id,
$context).. It seems odd to me that the code isn't specifying the type
of event explicitly. You say that the handler for this type of event is
the only code that needs to understand the $context. What if I just
want to list all the hold pickup events that are stored, would my query
need to be based on the contents of the JSON encoded $context variable?
What about having some events be deferrable, as a per org unit/user
setting. This would help facilitate batching of event type delivery.
Each org could decide if things like Max fines reached or Account
Expired events (or any other event type) delivery can be deferred for a
certain amount of time in order to be batched together with other
notices. For things like Max fines reached, or account expired the
delay could be as much as 48 hours or more. For hold pickup events it
could be 4 hours, with certain cutoff times such as 11:30am and 4:30am
to ensure customers are informed in time to stop by at lunch or after
work. Canceled hold events would be another one that could be deferred
for quite some time in many situations.
I'm a big believer in minimizing the individual number of notifications
that a customer receives in total, since they system I currently have
experience with handles it so poorly. Currently I can get, one email
for a hold filled in the morning, another email for a hold filled later
in the afternoon, another email for a pre-overdue notice at 6am, another
2 emails for overdues if the two items have different home locations
Sigh.
Josh
