Bug 12809 - Failures in Koha notifications systems
Summary: Failures in Koha notifications systems
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P3 enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-22 16:57 UTC by Fred P
Modified: 2016-12-09 00:16 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
There are too many unrealistic letter and delay combinations. (107.45 KB, image/png)
2014-08-22 16:57 UTC, Fred P
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fred P 2014-08-22 16:57:13 UTC
Created attachment 31105 [details]
There are too many unrealistic letter and delay combinations.

The Koha notifications system has four main components:

1. A message_transport_type for each notification method
2. A letter or "notice" for each of the message_transports
3. A "delay" and "letter" selection process for overdue actions.
4. The option of "EnhancedMessagingPreferences" allowing patrons and staff to define specific patron notifications.

In the staff interface, we refer to defined letters both as "notices" and sometimes as "letters." Overdue notices get a separate interface, allowing three letters to be selected to send. Creating a single framework for pre-due and overdue notifications would simplify the process of configuring specific patron settings.

Goals for improvement should include:

1. Define a more consistent notifications failover chain - either user-defined or pre-set to "SMS > Email > Phone > Print Notice." Consider points #4 and #5 below - how is this affected when we add a new message_transport_type, or if we combine all notifications into one framework? A numeric priority should be set for the message_transport_type, and should failover in that order. Adding a new message_transport_type would force re-sequencing of those priorities.

2. Combine SMS number (Patron Messaging Preferences) with patron's mobile phone number. I can't imagine these would ever be different in practice. Instead of requiring a separate "SMS number" to be defined, we should simply use the patron messaging preference's SMS checkbox to select SMS messaging to the mobile number. At the very least the mobile number should populate the SMS field, because there is no way to define the SMS number through the New Patron memberentry.pl script.

3. Allow "Days in Advance" to function for Advance notices, by enabling user to activate the "takes_days" flag in the message_attributes table.

4. The "letter" selection process in overduerules.pl is extremely flawed. For example, you can set a delay on an advance notice, but it in practice, this doesn't function the way you would logically expect. We need to combine pre-due and overdue notifications, perhaps by using a "negative" days in advance value, or a "days before" and "days after" pull-down. 

 Combining pre-due and overdue notices will reduce confusion both in the user interface and in the batch processing of notifications. We already define all notices or "letters" through a single letter.pl script. We should also implement one process to send out both pre-due and overdue notifications, and one interface to specify every outgoing message, with a goal of simplicity and de-duplication of function.

5. Allow new notification methods to be defined in the message_transport_type table. For example, we should be able to tag specific patrons for automated phone calling through I-Tiva with a user-defined "Itiva" message_transport_type.

Thank for considering these idea! I may be missing different use cases, but I can see clear advantages to streamlining and combining the notifications processes.
Comment 1 Fred P 2014-08-22 21:11:57 UTC
It has been pointed out to me that I should not be delaying advance notices in Goal #4 because you don't send an advance notice for an overdue. Yes, I think that is my point. Overdue notices and reminders should be flagged as 1st 2nd and 3rd letter choices, while "Reserve Slip" should not be available as a selection. This would require an Overdue Notice flag on new Notice creations, to indicate availability in the 1st 2nd and 3rd letter pull-downs.

Looks like goal #5 is available in 3.16, so drop that off the list.

Patrons currently pick their notification preference through Enhanced Messaging Preferences, and that will override the default failover, which looks for SMS number or e-mail address before calling with iTiva or generating a print notice. So maybe goal #1 is almost there - I am imagining being able to see into the failover order so it is obvious how my message will generate - before it is sent.

A pre-due tab could be added to overdue triggers page, which would make logical sense because it is also a form of overdue notice, but the delay value could function as an advance value.

Separating the overdue notices from other notices in the Notices and Slips interface would help determine which letters can be assigned in the overdue triggers interface. Perhaps this is the most do-able change.

I'm changing this to "Enhancement" as I am seeing a lot that does already work within the current notifications system.