Notices Overhaul RFC

Notices Overhaul RFC

Status:	unknown
Sponsored by:	Brimbank Libraries
Developed by:	Catalyst IT
Expected for:	2018-11-01
Bug number:	Bug 20962
Work in progress repository:
Description:	Currently notices are run using effectively two separate systems. Overdue notices run using their own cron job, whilst everything else is either queued by the advance_notices cron or directly added to the message queue. Additionally, print overdues are treated differently to other overdues. This means the options available for print overdues considerably lag those available for other notice types, and there are confusing discrepencies between overdues, other notices, and print overdues and everything else.

This proposed overhaul would would be broken into a number of steps that can be implemented in order.

Step 1 - Move Overdues into member messaging preferences

Overdues should be brought into the member Messaging Preferences. This should allow patrons (or staff on behalf of patrons) to:

1. Select one or more notification methods (SMS, email etc)

2. Choose not to be notified about Overdues at all (NOTE: this would default to OFF and have to be explicitly allowed by the library on a borrower-category basis)

Note: There are potentially multiple levels of overdues. All should be included in one notice type for messaging preferences.

Step 2 - Enable 'postal' as a specific option rather than simply a fallback,for all notice types

This would align with providing an option to not receive notifications at all for overdues (see above), and be clearer for Koha administrators.

Step 3 - option to process all print notices together

Currently print notices are processed by Library, meaning a library service with multiple branches will receive one email per branch with the csv or PDF file for print notices. There should be the option to either retain this behaviour (useful in, for example, consortia) or alternatively to send all print notices in a single email.

Step 4 - extend <item> tags to other circulation notices

Extend availability of <item></item> tags to all circulation related notices (e.g. holds), allowing for more customised notices.

Step 5 - Allow for 'digesting' of all notices in queue regardless of type

This would be an additional option in the member messaging preferences that would 'digest' all notices, or all notices of a particular type, sent in the same message queue process. For example, there may be hold notifications, multiple levels of overdue notices, and a membership renewal notice for a particular patron on a single day. It should be possible to print all of these on a single notice, if that option is chosen, or all notices of each type (e.g. all hold notices), if that option is chosen.

Alternatively, at the very least there should be the option to send Hold Available notices as a digest. This doesn't really matter for email and SMS, but would be very useful for print notices.

Step 6 - Allow circulation notices to be created for any item status change

This would be a bigger change, potentially out of scope by the time we get to here.

The general principle would be that there should be the option to send a notice if an item status is changed on a currently issued item. Primarily this would be useful for DAMAGED, and LOST, though the reasons for LOST being useful may be surperseded by Bug 14697 as 'Claims Returned' would be the obvious use case. The other use case I can currently see is if something is returned incomplete (e.g. an empty DVD case), but the point of making this change to notices is to allow flexibility rather than creating new features specific to a particular workflow.

How it might possibly work

In Notices and Slips (letter.pl) notices using the Circulation module would additionally have an optional 'Status Code' and 'Authorized Value'. If both exist, that notice type is triggered by a change to the status type matching the status code (e.g. DAMAGED) to the value specified (e.g. '1'), when an item is on loan. In the case of a LOST status type, obviously the item will be returned when the status is applied, so it will need to account for that and grab the patron it was issued to at the time the status was applied.

These notices must have the ability to use <item></item> tags so that use-case specific information can be used. NOTE: Jonathan Druart has pointed out this is being deprecated in favour of TT syntax, so this will be checked to ensure access to all relevant item and borrower account information.

Step 7 - consolidate overdue notice triggers into main notices page

This would standardise how triggers are set up, either triggers for overdues, or triggering off a status change: including how long before/after the trigger event the notice is generated.

Step 8 - Do not disturb for message queue

This would allow library admins to set a 'do not disturb' period (in the notices interface, not just in a cron job) for each notice type, so that messages of that type can be processed as usual but not triggered during that period. For example, you might want emails to the librarian to be queued and sent 24/7, but overdue notices not added to the message queue between 8pm and 8am. This would allow the notice generation time to be say, 2am, but the notice sending time to be 8am when you won't wake people up with a random SMS. This splits out the resource-intensive notice generation queries from the relatively lighter message queuing.