[Koha-devel] Notifications RFC

Fri Aug 26 14:28:58 CEST 2011

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.
   - <item/> is only supported in Overdues, not in any of the Advance
      Notices or Hold notifications
      - <<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.
   - For overdues (and possibly advance notices as well) the Koha branch
      email or admin email are sent the document of all the
undeliverable message.
      - 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.
      - Overdues and Advance Notices have an HTML option, which works
      completely differently, but produces the same net effect:
notices files on
      the server
      - 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

On Fri, Aug 26, 2011 at 2:24 AM, Mason James <mtj at kohaaloha.com> wrote:

>
> On 2011-08-26, at 3:47 PM, Mason James wrote:
>
> >
> > On 2011-08-26, at 4:08 AM, Elliott Davis wrote:
> >
> >> Hey Guys,
> >>
> >> I have noticed of late that notifications is in quite a state of
> disarray.
> >
> > snip
> >
> >>
> >> Essentially what I would like to do is model notifications to do the
> following:
> >>
> >> 1.       Base notification rules on patron type, item type, and a new
> grouping I am hoping to write that I am calling the collection code
> >> 2.       Define a frequency for notifications based on the previously
> stated groupings
> >> 3.       Base the start time and end time for notifications on the due
> date rather than the checkout date
> >>
> >
> > fyi, Koha's notifications not doing feature (x,y,z) does not equal 'in
> quite a state of disarray'
> >
> > last time i looked the code was pretty clean and extendable?
> >
>
> ooh, my last comment sounded a little condescending there :/ (friday brain)
>
> but hey, my point still stands...
> the notifications code could be modded to handle your 3 features without to
> much trouble, i reckon...
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110826/5b0e2459/attachment.htm>