unknown

Sponsored by no-one yet and developed by no-one yet, expected for/deadline: unknown

Description

Not yet described here. See Bugzilla entry.

Meeting Document from 8 September 2011

Note that this was originally in colour over at http://typewith.me/3gYf6ozqf4. Go visit. There was a really cool text chat sidebar, too.

Textual Direct to Patrons NOTIFICATIONS OVERHAUL

Areas to be covered:

messages (editing, formatting, ...)
delivery of messages (how? when? how often?...)
triggered actoins?...

Messages:

Circulation:
- Overdues
  - 3
  - allow more
- Predues / Advance notices (allow more than 1, range 0 - unlimited days before due date)
- Due (1 only)
- Checkin
- Checkout
- Fine levied (I like that idea - could be send out as a reminder when books have already been returned)
- Recall - be able to set a shorter due date and send a letter to the patron telling him the new date and ask to bring the book back <- probably important for hourlies anyway, SMS best for this. <- it's also nice if you allow long loan periods for professors - inform them when someone else wants the book and shorten the loan period. We use a report now to find those holds and you can renew to a shorter loan period - but you can't inform them automatically
- Renewal (I think there is some development for this on bugzilla now)

Holds
- Hold placed (patron* and/or librarian)
- Hold waiting
- Hold expiring
- hold queue position update* Mean! Some people are micro-managers! I know, but it will bring all to the light! :)The truth will out the queue hoppers!
- hold cancelled - say if you had a hold on an item that was lost and wanted to notify the patron that the hold had been cancelled <- good!

Members
- patron creation
- account expiration*
- address change (patron (not hardcoded, translatable*) and libarian*)

Acquisitions
- Email order* (PDF attached or text only)
- Claim notices (currently not done via message_queue)

Suggestions
- Placed
- Accepted
- Rejected
- Ordered
- Available

Serials
- New serial issue for X has arrived
- Claim notices (missing issues)

Cataloging*
- Fast Add material added* (to librarian, indicating full cataloging needs doing)
- Newest materials* (for RSS)

Reports*
- scheduled report results*

News*
Library events* - perhaps tied to calendar? Send out newsletter like information about this event 3 days before it's happening to patron categories X and Y
Inform patrons about sudden change of opening hours or changes to circulation rules etc.

new ideas currently not available in Koha [Double check these here, I took some * out for formatting.]*

Delivery types

(how the message gets transmitted)

Make this as extensible as possible, so new transmission methods don't involve writing the functional bits of the code (to help avoid regressions in the face of new features)

Internal (messages in OPAC and staff client)*
Email
Print (make those downloadable from intranet)
SMS
RSS*
Facebook?*
Twitter?*
Identica DM?*
Google+?*

Message formats

(limits on the message structure and editor)

plain text
HTML -> to PDF via browser for best Unicode support*
RSS (XML)*
short message (140 char limit) <- isn't it 160 chars? twitter is 140, SMS is 160

If it's html, could do cover art + library logo to jog a patron's memory.

Message format determines editor:

plain text is plain data entry box
HTML gets WYSIWYG
RSS gets similar RSS WYSIWYG
short message gets char limit

Delivery Timing:

SMS should never be sent at localtime night, say between 9pm and 8am) (idea: add SMS hours to patron account; they can specify when they are willing to receive SMS messages) See below for same idea with email For a general default, this could be checked against the local ordances for quiet enjoyment. Just about everywhere has one in the US.

Triggers

There are two kinds of event triggers: action based (checkin, checkout, etc), and scheduled (overdues, advance notices,etc). Action based triggers are 'hooked' into code sequence at specific time, where as scheduled triggers run off crons (or maybe a Messaging Daemon (great idea)) I really like the idea of abstracting the types of triggers available FWIW sounds good to me So, if we have a daemon, it can either be sent a message to send (an action-based triggering), or programmed to generate and send scheduled messages at the appropriate intervals (not just nightly; need hourly/minutely checks for SMS overdues, say) we should keep the messages logged in the message_queue - it's good for reporting. Perhaps enhance to library can check it easier. I actually like the way the notices are displayed on the patron record, fwiw (can always be better tho)

i think still want to merge the notices and notice tabs or however they are calle din english and add an option to see the formatted text - as it is now it's very hard to read <- this, yes :)

Message Logging

Optionally keep this data, and make accessible to staff

Clean out regularly? Let patron decide? Tie into patron prefs about messaging and circ history?
- agreed; make messaging privacy just as accessible to patron as circ history and search history privacy. At this time, privacy means "the patron cannot see the information anymore", not "the information is lost forever" (at least in the case of circ history)
- I see a problem with that for overdues - you want to keep them until the fines are paid and checkouts are returned - so you have to define 'active' notices' that are not to be deleted
- ^^ if you do a current queue I think that would take care of this issue. If we were to set up a queue for the daemon we could say whatever is in the queue is currently active. If the patron has the "keep" privacy prefs set then we archive the message, discard if not. - sorry, don't understand that...any better? hm yes, btnot sure it solves my problem :) - when would a message stop being in this queue? for overdues you want to keep them for weeks or longer. when an item was (insert reason for resolved notice here) then they would be removed from the message queue ok :)
Message title
Formatted! Message
delivery status (failed, sent, pending...) + timestamp
delivery method
It would be cool to do some reporting on bounces too, but I don't see a good way for koha proper to deal with that, as it's a mailer function and the reply-to is set to the library's address <- do we want to make reply and sender's address configurable by message type?
- Sender address and reply-to should be independently configurable, by branch. (so bounces go to the right place)
- Auto add a note to the patron if email notice bounces
- I think that the Reply-To address should be configurable my message template (so each branch could have it's own reply-to for Overdues, say, or Alumni could be directed to Alumni office while current students are routed to the main library email)
- Maybe a daemon on the server to check the bouncy mail, running as it's own user.

- Messages Selection criteria:
Branch
Patrons
Item Types [*]
collection code
shelving location?
- I would argue that if we start allowing codes other than the Core 3 (branch, patroncategory and itemtype), we should allow ANY such code at the library's discretion. Code all 'meta' around different item and patron codes.
Patron Preference:
- Librarian chooses which messages are mandatory and which are optional
- Patron chooses when they're willing to receive each optional message, and in what format
  - Example: Predue notification - 15 min before due - SMS - between 8am and 9pm

Predue notification - 1 day before due - Email - anytime Due notification - at due time - Facebook DM - 7am to 10pm I'm hesitant to use facebook but only becuase their API got voted worst of the year I don't think we should make it a priority, but if someone wants to code the integration, then our structure should allow for it without having to make any major revisions Can we make the library decide for which messages the patrons can decide what to do? I think most libraries don't want borrowers to change settings for overdues Yes. We can set it up so only certain messages can be controlled by the patron. Overdues would continue to be mandatory, but this would give us the option to make, say, PreDue or Holds notification, also mandatory

Triggered actions
- sending message
- debarment
- unlimited
- for X days
- until fines are paid
- until checked out books are returned (?)
- fine
  - have different amounts for each overdue level (important to German libraries)
    - is this based on an algorithm or is it a manual entry?

example: 1st notice: 1.50, 2nd: 5.00, third: 10.00 or more, not steady

Not sure where to add that

messages should be times using the calendar, like you can do with fines now ignore holidays for calculation use next opening day when calculated date is a holiday ignore calendar messaging prefs as far as email times etc (I hate getting emails early on my phone becuase it wakes me up)Is this redundant to delivery timing? Line 81

Charging interval & grace period calculation At the moment if you use a weekly fine interval the system will give a week as grace period, there is no way to avoid this. It's always at least one interval. What we need is: Date Date, an adjustable grace period, send first notice and add first fine, send second notice after fine interval

Message contents Have readable translatable explanations in addition to table.field Pre made additional fields <<today>> <<list of items>> <- fields should be configurable in GUI, not only on command line Option to define your own fields with sql statements/reports total of fines for borrowernumber x total of checkouts for issue y selected fields are tokenizable

Notes for development

have a branch on the koha git repo or public repo of its own

CPE example

Messaging rewrite RFC

Contents