[Bug 43968] New: Replace FallbackToSMSIfNoEmail with a configurable message transport fallback order
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43968 Bug ID: 43968 Summary: Replace FallbackToSMSIfNoEmail with a configurable message transport fallback order Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: martin.renvoize@openfifth.co.uk Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: martin.renvoize@openfifth.co.uk Depends on: 21781 Target Milestone: --- Bug 21781 extends the FallbackToSMSIfNoEmail system preference, which started as a way to send purchase suggestion notices by SMS to patrons without an email address, to more notices. Working on it showed the on/off preference is too narrow: it only knows about email falling back to SMS, and the notices it covers are decided in code. Proposal: replace it with an ordered list of transports to fall back to, set once for the whole system, for example: email, sms, print When the transport a notice should be sent with is not usable for a patron (no email address, no SMS number or phone), the next transport in the list that the patron can receive is used. Per notice type, a library opts out by not defining a notice template for a transport: a transport without a template for that notice is skipped. An empty list means no fallback. Details: - New system preference (name to be decided, e.g. MessageTransportFallbackOrder) holding the ordered transports; FallbackToSMSIfNoEmail is removed and its value migrated in an atomic update (enabled becomes "email,sms", disabled becomes empty). - One place to resolve the transport for a patron and a notice (building on Koha::Patron->message_transport_type_for from bug 21781), used by the notices that currently hard code a transport and by Koha::Patron->queue_notice, which today always falls back to print. - Only explicit transport sends follow the configured order. Notices sent according to the transports a patron chose in their own messaging preferences are left as they are. - Tests, and documenting the behaviour (the preference text, the manual). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21781 [Bug 21781] message_transport_type should allow fallbacks -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43968 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 210159 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=210159&action=edit Bug 43968: Replace FallbackToSMSIfNoEmail with MessageTransportFallbackOrder FallbackToSMSIfNoEmail could only make email fall back to SMS, and which notices it applied to was decided in code. Replace it with a single ordered list of message transports to fall back to, for example 'email,sms,print'. When a patron cannot be sent a notice with the transport it would be sent with (no email address, no SMS number and SMS driver, no phone number), the transports that follow it in the list are tried, and the first one the patron can receive is used. A transport only gets used as a fallback if the notice has a template for it, so a library opts a notice out of a fallback by not defining a template for that transport. If nothing can be used, the notice is sent as it was before. Left empty, there is no fallback. As before, only transports asked for explicitly fall back this way: the transports a patron chose in their messaging preferences are left alone, and still fall back to print. The atomic update moves the value of the old preference: enabled becomes 'email,sms' and disabled becomes empty. To test: 1. Apply the patch and run the database update => If FallbackToSMSIfNoEmail was enabled, MessageTransportFallbackOrder is 'email,sms', otherwise it is empty 2. prove t/db_dependent/Koha/Patrons.t t/db_dependent/Suggestions.t \ t/db_dependent/Acquisition/NotifyOrderUsers.t 3. Set SMSSendDriver and MessageTransportFallbackOrder to 'email,sms,print' 4. For a patron with no email address and no SMS number, receive an order they are notified about (ACQ_NOTIF_ON_RECEIV) => A print notice is queued 5. Give the patron an SMS number => The notice is queued as SMS, using the SMS template 6. Delete the SMS template for ACQ_NOTIF_ON_RECEIV => The notice is queued as print Sponsored-by: OpenFifth Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43968 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Patch attached. It builds on bug 21781 (the first patch here is the only new one; the 21781 patches are on that bug), so it needs that bug to land first and a rebase after. Summary: FallbackToSMSIfNoEmail is replaced by MessageTransportFallbackOrder, an ordered list such as email,sms,print. When a patron cannot be sent a notice with the requested transport, the transports after it in the list are tried and the first one the patron can receive, and that has a template for the notice, is used. Leaving a template out opts a notice out of that transport. Only explicitly requested transports fall back; patron messaging preferences are unchanged. An atomic update migrates the old value (enabled -> email,sms, disabled -> empty). -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org