[OPEN-ILS-DEV] notifications (internals)

[Josh Stompro]

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