[OPEN-ILS-DEV] Notification system design

[Nathan Eady]

Mike Rylander wrote:

> There are no design docs for the notification infrastructure as yet.
> This was nearly all Bill's stuff, so I don't know how far we should go
> while he's not around to defend himself ;), but a generalized
> notification service is something we've discussed (and makes sense, if
> more than email notification is desired).

Indeed.  This is something that should be discussed in some depth
before being implemented.  Notification procedures vary quite a lot
from one library to another, so what works for one library system
will not necessarily work for another.

> There are two competing types of "triggers" we'll need to consider
> here:  real-time, action based triggers (hold arrives at its
> destination; fine is generated on an overdue item), and time span
> expiration triggers (item is 14 days overdue; hold fulfillment is
> taking forever, would you like to try other formats/editions?).

There are also the "queue it for the next time we do this" kind,
which is what would be needed e.g. for old fashioned postal
notifications and billers.  This gets a little complicated because
if the item is added to a queue by a trigger event, then later when
the queue is processed something has to check whether it's still
appropriate, and also whether it can be combined with other
notices going to the same address, so the queue may need fields
it otherwise wouldn't require (e.g., patron record ID, item
record ID) to allow for this sort of checking.

And yes, postal notification is going to be worth implementing
at some point.  In small, somewhat technophobic Galion, we
currently have email addresses for roughly half of one percent
of our registered patrons.  That number will go up over time,
but I think this illustrates that postal notification is not
going to be a thing of the past -- at least, not for all
libraries -- for a good number of years, perhaps decades.

Also, some large library systems want to handle notifications,
especially postal ones, in a decentralized fashion, with each
library or branch mailing out its own (so that the postage
comes out of the correct budget, the correct letterhead is
used, or for whatever reason).  So you end up having to decide
things like whether the notice should show up in the patron's
library's notice batch, the item's library's, or the checkout
library's batch -- and if you send notices from the item's
branch or the checkout branch, then how do you combine notices
when a patron has items overdue from multiple branches, and
so forth.  Some of this can be left unimplemented in a first
release of the notificiation system and filled in later, but
the design needs to take them into account so that the whole
thing won't need to be rewritten to add them.

And you don't want to require libraries with simple needs
(e.g., all notices are sent from the main library) to deal
with the complexity they don't need, so the design should be
able to accommodate simple default settings.

> The first of those, in our experience, is served well by a full
> fledged OpenSRF service.  An example of this is the penalty server,
> where any change to a user's circulation, hold, or fine standing
> causes a recalculation of their penalties (blocked, delinquent, etc).
> The second type, examples of which are the current overdue notices and
> collections listing, is usually handled by a nightly process.  Both
> end up in some sort of notification to someone, and collecting them in
> a pluggable service sound like a good idea to me.

Postal notifications could be generated by a nightly service,
initially (which is what some ILSes do), but you'd still want
to check when the staff go to actually "run" them (i.e., do
whatever it takes to get them printed) to see if they are all
still appropriate and whether some can be combined.  I can tell
you for certain that some libraries do these once a week, and
that sometimes if somebody's off work that day they get delayed
further.  By then, some of the generated notices sitting in the
queue don't need to be sent, and others can be combined (e.g.
if a single patron has two overdue items with two different due
dates, so that the notices were not added to the queue on the
same night, they still should be sent on a single page).

> Some things to think about:
> 
> * we'll need a persistence model -- if reporting on notifications is
> desired then it should probably be rolled into the central database
> schema

It seems reasonable that "pending" notifications (i.e., those that
have been triggered or queued but not yet sent) should inhabit a
table in the database.

A further complication is that some libraries expect to send
multiple notices at different intervals -- e.g., a library might
want to send a "warning" notice shortly before the grace period
expires, an "overdue" notice some number of days after the grace
period expires, a "long overdue" notification a month or so
later, and a "biller" when the item is charged to the patron's
account.  Each of these might have somewhat different wording
and possibly contain different details about the item, and in
a some cases you might be sending more than one level of these
notifications to the same patron at the same time.

There are also other _kinds_ of notifications, e.g., you have
an item on hold, waiting for you to pick it up.  Again, in weird
cases you might be sending one of these and also an overdue notice
to the same patron at the same time.  With email you might not
care if they're left separate, but for postal notifications or
phone calls you almost certainly want them combined.

> * should there be two service types  -- "action" triggers and
> "scheduled" triggers -- or should there simply be a polling process
> that fires time-based events, OR should all be scheduled allowing for
> a delay in "actions" (for example, a held item arrives but is damaged
> and can't fulfill the hold -- so no notification should be sent)

When an item comes in but is dammaged, you don't want to trigger
a hold, but it would be possible to handle that outside the
notification system, by having the check-in code verify that the
item is ready to hold before triggering the hold in the first
place.  You probably want to get the checkin staff's attention
anyhow, so they can place the item on the hold shelf instead of
the reshelving cart (or whatever), so it might be reasonable to
ask the user something along the lines of "There is a hold
request on this item.  Hold it on the reserve shelf?" with
options like "Hold Now", "Later", and maybe "Cancel Hold".
(The message may get more complicated or at least will be
a bit different if the item is to be held at a different
branch from the checkin location, but the idea is the same.)

If the user chooses the "Later" option, they can then do
other stuff like mark the item "Dammaged", pull it for a
special display, check it out to the board member who just
walked up to the desk with it, or whatever the circumstances
demand, and the question gets asked again the _next_ time
the item gets checked in (or, if the hold is on a bib record
with multiple items attached, the next time any of them gets
checked in).

However, even if we go that way, this really only deals with
your example, not with the underlying question you were asking.
The question of having a delay built in would still be interesting
e.g. for situations like Don McMorris mentioned.

> * where do we delimit plugins -- should there be plugins for both
> accepting/recording events and firing/performing notifications

At the very least each library system should be able to configure
how things work at both those points, I would think.

>> I know where the email notification files are at now, and I see that
>> automated phone notification is on the feature list for a future
>> release, is there anything about how it all is going to be tied
>> together, or about what events trigger notices, and about other forms of
>> notification (SMS, IM, Telegraph, Smoke Signals, Exchange Calendar
>> Events, etc).

Another form of notification some libraries use is phone notification
performed by a human -- i.e., a library employee reads down a list
and calls them.  (For instance, we do this for holds, except for
patrons who have email notification enabled, and we do it for the
first overdue notification for most patrons.)  It would be really
cool if this list were generated by the same system as generates the 
other kinds of notifications.

Which brings up a further wrinkle:  ideally you'd want individual
patron records to be marked "Don't use this type of notification",
for any given type of notification that the library uses.  Then
there needs to be a notification type priority list or schedule or
whatever that can designate policies like, "For hold notifications,
send email if possible, but if the patron has email notification
disabled fall back to automated phonecall, and if that's disabled
also then send a postcard."

> The nice thing about email is that there are gateways from it to other
> services like IM and SMS.  Even a phone notification system could use
> text-to-speech to allow an email gateway, I think.  (Asterisk may even
> have this today ... not sure.)

But text-to-speech *sounds* like text-to-speech, and some libraries
might prefer a system with larger segments of pre-recorded message,
using text-to-speech only for names and titles and such.  (I'm not
sure that has any real impact on your main point, though -- an
email message could still be used as a carrier to get the information
about the specific notification to the calling system, if that's
how you want to design it.  It seems a little odd, but assuming
you use a dedicated mail server it should work okay.)

> iCal generator for a patron's current checkouts, perhaps?

Now that sounds to me like an accessory function that could be
built into the catalog, independent of the main notification system.