https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |baptiste.wojtkowski@biblibr |ity.org |e.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Anneli Österman <anneli.osterman@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anneli.osterman@koha-suomi. | |fi --- Comment #2 from Anneli Österman <anneli.osterman@koha-suomi.fi> --- We use a JavaScript to check that the patron has email address or sms number when the corresponding messaging preference is selected. If they do not have email address/sms number and the preference is selected, the script removes the selection (and notifies the staff about the removal). This naturally works only when the patron infromation is modified or created. Maybe this kind of function could be added to Koha? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |dcook@prosentient.com.au |y.org | --- Comment #5 from David Cook <dcook@prosentient.com.au> --- @bwoj if you want to write that patch I can test and QA it -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- So yeah... you'd be better off reverting the change and then adding a 2nd condition where it's 'if (!$notitication_sent && $notification_required)' or something like that, and you can increment that $notification_required within the loop. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- Created attachment 207015 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207015&action=edit Bug 42809: Fix messaging preference 'print' fallback This change fixes the conditions around the messaging preference 'print' fallback, so that the print fallback is only used if the user has (1) messaging preferences defined for this notice, and (2) the user does not have the metadata needed to fulfill *any* of the messaging prferences (ie 0 preferred notices could be generated) To reproduce: - Set SMSSendDriver syspref to Email - Using KTD, search for patron with cardnumber 42 - Go to the "Details" tab and "Edit" the "Patron messaging preferences" - For "Hold filled" tick both SMS and Email and click Save - Place a hold for the user - e.g. Search for biblionumber:"29" - Go to Holds - Put 42 in the search box - Hit "Search" button - Hit "Place hold" when the hold screen comes up - Check in the item for biblionumber 29 - e.g. On the top bar go to the "Check in" tab and enter 39999000001310, and press the arrow button - Click "Confirm hold(Y)" - In the patron record, go to "Notices" and note that thre's a print notice generated. This is to be expected since we don't have an email stored yet. - Now cancel the hold, add an email address (doesn't have to be real), and repeat the hold placed and hold filled process above - Note when there is an email address but no SMS number, we have both an "email" and a "print" notice generated. This is the bug! - Edit the user and remove the email address but add a SMS number - Now cancel the hold, and repeat the hold placed and hold filled process above - In the patron record, go to "Notices" and note that we have both a "print" and a "sms" notice generated. This is also the bug! - I'm not quite sure how sure how to check the itiva and phone notifications, but the above should be sufficient to illustrate the bug -- To test: - Apply the patch - restart_all - As per "To reproduce", cancel any holds for user with cardnumber 42 - With a SMS number but no email, repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only a SMS notice is generated - Cancel the hold - Remove the SMS number and add an email address - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only an email notice is generated - Cancel the hold - Remove the email address so there is no email address nor a SMS number - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only a print notice is generated - Cancel the hold - Remove the messaging preferences for "SMS" and "Email" - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that no notice is generated - Cancel the hold -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- Technically, the best solution would be to create a Koha::Patron method like Koha::Patron->available_messaging_transports(), and unit test that, but... I just wanted to fix the bug ASAP. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #11 from David Nind <david@davidnind.com> --- (In reply to Baptiste Wojtkowski (bwoj) from comment #10)

On main on ktd while reproducing bug I could not manage to get a print notice when setting the hold, am I missing something ?

I was able to reproduce the issue before the patch: 1. SMSSendDriver system preference set to Email 2. Messaging preferences for the patron: Hold filled = SMS and Email selected 3. No SMS number or email address: ==> Print notice generated 4. No SMS number but has an email address: ==> Print and sms notices generated 5. An SMS number but no email address: ==> sms notice generated -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207015|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes the generation release notes| |of patron notices. If a | |patron had an email address | |but no SMS number, both an | |"email" and a "print" | |notice were generated. Now, | |only an email address is | |printed. | | | |Example scenario: | |1. SMSSendDriver system | |preference set to Email | |2. Messaging preferences | |for a patron: Hold filled = | |SMS and Email selected | |3. No SMS number or email | |address: | | ==> Print notice | |generated (as expected) | |4. No SMS number but has an | |email address: | | ==> Before the fix: | |email and print notices | |generated (this was the | |issue this bug fixes - only | |the email notice should | |have been generated) | | ==> After the fix: email | |notice generated (now works | |as expected) | |5. An SMS number but no | |email address: | | ==> sms notice generated | |(as expected) Summary|Notification falls to print |Notification falls to print |back when two messaging |back when two messaging |preferences are set but |preferences are set but |only one is valid. |only one is valid -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |bibliothek@th-wildau.de |y.org | CC| |bibliothek@th-wildau.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 --- Comment #15 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Baptiste Wojtkowski (bwoj) from comment #14)

@Jan Kissig would you mind signing off and I take the QA ?

hey @Baptiste Wojtkowski, yeah I started QA on this and got stuck while trying to enable "digests only" fallback print notices. Maybe you can look at it and of course you can take the QA here. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 --- Comment #16 from Jan Kissig <bibliothek@th-wildau.de> --- Created attachment 207899 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207899&action=edit Bug 42809: Fix messaging preference 'print' fallback This change fixes the conditions around the messaging preference 'print' fallback, so that the print fallback is only used if the user has (1) messaging preferences defined for this notice, and (2) the user does not have the metadata needed to fulfill *any* of the messaging prferences (ie 0 preferred notices could be generated) To reproduce: - Set SMSSendDriver syspref to Email - Using KTD, search for patron with cardnumber 42 - Go to the "Details" tab and "Edit" the "Patron messaging preferences" - For "Hold filled" tick both SMS and Email and click Save - Place a hold for the user - e.g. Search for biblionumber:"29" - Go to Holds - Put 42 in the search box - Hit "Search" button - Hit "Place hold" when the hold screen comes up - Check in the item for biblionumber 29 - e.g. On the top bar go to the "Check in" tab and enter 39999000001310, and press the arrow button - Click "Confirm hold(Y)" - In the patron record, go to "Notices" and note that thre's a print notice generated. This is to be expected since we don't have an email stored yet. - Now cancel the hold, add an email address (doesn't have to be real), and repeat the hold placed and hold filled process above - Note when there is an email address but no SMS number, we have both an "email" and a "print" notice generated. This is the bug! - Edit the user and remove the email address but add a SMS number - Now cancel the hold, and repeat the hold placed and hold filled process above - In the patron record, go to "Notices" and note that we have both a "print" and a "sms" notice generated. This is also the bug! - I'm not quite sure how sure how to check the itiva and phone notifications, but the above should be sufficient to illustrate the bug -- To test: - Apply the patch - restart_all - As per "To reproduce", cancel any holds for user with cardnumber 42 - With a SMS number but no email, repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only a SMS notice is generated - Cancel the hold - Remove the SMS number and add an email address - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only an email notice is generated - Cancel the hold - Remove the email address so there is no email address nor a SMS number - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that only a print notice is generated - Cancel the hold - Remove the messaging preferences for "SMS" and "Email" - Repeat the process for placing and filling a hold outlined above - Check the user's notices and note that no notice is generated - Cancel the hold Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jan Kissig <bibliothek@th-wildau.de> -- You are receiving this mail because: You are watching all bug changes.