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@lists.koha-community.org Reporter: fred.pierre@smfpl.org QA Contact: testopia@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.