[Koha-devel] Notifications RFC

[LAURENT Henri-Damien]

Le 26/08/2011 14:28, Ian Walls a écrit :
> Problems I see with Notices:
> 
>     * Overdues are limited to 3 per patron.  This needs to be unlimited,
>       so a more robust triggering methodology needs to be put into
>       place, along with tie-ins to fines and privilege restriction
>     * Advance notices are limited to 1 predue and 1 due.
>     * Overdues have two competing syntaxes for item information,
>       <<items.content>> and <item></item>, neither of which are
>       particularly good. 
>           o <item/> is only supported in Overdues, not in any of the
>             Advance Notices or Hold notifications 
>           o <<items.content>> has to be specified on the commandline,
>             adding sysadmin's to the customization process.
>     * Predue and Due both have separate digest forms, instead of
>       notation that could be flexible enough to handle one or multiple
>       items at a time.
>     * Advance Notices cannot be mandated by the library like Overdues
>       are; what if you want to guarantee your patrons are being sent
>       hold notices?
>     * Overdues cannot be opted into by patrons (I can see no opt-out,
>       but what if you've configured a patron category to not receive
>       overdues, and someone within that category wants to be notified
>       because they're responsible, if a little forgetful?)
>     * Handling of notices to people without email addresses is
>       inconsistent.
>           o For overdues (and possibly advance notices as well) the Koha
>             branch email or admin email are sent the document of all the
>             undeliverable message.
>           o For holds, a completely different HOLD_PRINT notice form is
>             used, as well as a separate script to gather the notices, in
>             HTML, into a directory somewhere on the Koha server. 
>           o Overdues and Advance Notices have an HTML option, which
>             works completely differently, but produces the same net
>             effect: notices files on the server
>           o Nothing for checking/checkout notices
>     * Notices are mostly in plain text (except HOLD_PRINT).  Should have
>       HTML option, with a WYSIWYG editor.
>     * Message sending is sometimes handled by "process_message_queue",
>       and other times the messages are sent directly
>     * Overdue, Advance and Holds notices are completely incompatible
>       with Hourly Loans at this time
>     * Hold notices are broken out by Branch, Overdues can be too, but
>       Advanced Notices are global.  The use of the <<branch>> token has
>       proven quite buggy in my experience
>     * Meaning of "branch" can be unclear in some notice circumstances. 
>       Is it the patron's branch?  the item's branch?  The checkout
>       branch?  The currently-logged in branch?  Should it follow
>       CircControl?  HomeOrHoldingBranch? HomeOrHoldBranchReturn?  None? 
>       All, in different cases?
>     * SMS is not sufficiently supported; there are character limits that
>       need to be factored in.
>     * Notices do not make use of "reply-to" headers, which would make it
>       much easier for the conversation to continue, without having to
>       fine-tune the mail server settings on the Koha machine to match
>       the addresses of the branch administrators.
> 
> 
> So, I'm with Elliott.  The system needs an overhaul.  The difficult now
> comes with figuring out how to actually accomplish all this in the real
> world.  I recommend:
> 
>    1. more discussions to nail down a complete specification that meets
>       as many libraries' needs as possible
>    2. a meeting of the development team (whoever is willing to help) to
>       figure out the core architectural changes required, then
>       allocating work
>    3. filing separate bugs for each small component, with Depends On and
>       Blocks links.
>    4. Signoffs and QA on bugs 'in order', that is starting with those
>       that form the baseline of dependencies, then building off them
>       once they're in master.
>    5. Public test server so that librarians can easily check that the
>       specifications they laid out in the first place are actually met
> 
> Who's up for the challenge?
> 
> 
> -Ian
> 

Maybe it needs overhaul.
But some people already proposed something for that years ago
C4::Mailer.
It uses C4::Mailer for all the messages and a Template::Toolkit
definition for messaging. And tried to assign all the problems of the
Notification system.

One can see that there :
https://github.com/xercode/koha

has anyone tested it ?
About some of the problems raised by Elliot, it is not only notification
system but also issuing rules that would need overhaul... itemtypes, and
all that.
It would be nice to write some design with as many libraries as possible
and not only a few developers... Since those things are impacting Koha
as a whole.
My 2 cents.
-- 
Henri-Damien LAURENT
BibLibre