[Koha-bugs] [Bug 12809] New: Failures in Koha notifications systems

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12809

            Bug ID: 12809
           Summary: Failures in Koha notifications systems
 Change sponsored?: ---
           Product: Koha
           Version: 3.16
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Notices
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: fred.pierre at smfpl.org
        QA Contact: testopia at bugs.koha-community.org

Created attachment 31105
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31105&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.