Bug 9016 adds a UI for choosing transport types for overdues. The cronjob script misc/cronjobs/overdue_notices.pl should deal with this configuration.
Created attachment 20817 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW - 3 days * checkout B2 to P2 with a due date = NOW - 10 days * checkout B3 to P3 with a due date = NOW - 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level.
Created attachment 20818 [details] [review] Bug 10832: Multi transport types for overdue notices
Created attachment 20819 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW + 3 days * checkout B2 to P2 with a due date = NOW + 10 days * checkout B3 to P3 with a due date = NOW + 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level.
Applying: Bug 9016: DB changes: new table overduerules_transport_types Using index info to reconstruct a base tree... M installer/data/mysql/updatedatabase.pl Falling back to patching base and 3-way merge... Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Patch failed at 0001 Bug 9016: DB changes: new table overduerules_transport_types The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
This bug depends on bug9016 which is in status Needs Signoff but the patches for it do not apply cleanly
(In reply to I'm just a bot from comment #5) > This bug depends on bug9016 which is in status Needs Signoff but the patches > for it do not apply cleanly bug 9016 rebased.
Patch applied cleanly, go forth and signoff
----------------------------------------------------------------------------- -- "git bz applying 10832" on top of "git bz apply all commits for 9016" -- ----------------------------------------------------------------------------- Auto-merging misc/cronjobs/overdue_notices.pl CONFLICT (content): Merge conflict in misc/cronjobs/overdue_notices.pl Manually resolved the conflict. -------------------------- -- overdue_notices.pl -- -------------------------- overdue_notices.pl properly queues letters to koha.message_queue but the parse_letter() doesn't parse any letter placeholders <<branch.branchname>> atleast for email and sms transport type. Unsure if this is because of my merge. Placeholders work when triggering notifications from check-in/check-out for ex. Only tested the main path, unsure how to trigger secondary execution paths. Test plan works for the core test case. Yet to test the specific case, but based on my code review it should work :) Otherwise good work in such a complex application area. ------------------------- -- Failed QA because -- ------------------------- Merge conflict needs to be resolved. Placeholders do not work for some reason.
Created attachment 22815 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW + 3 days * checkout B2 to P2 with a due date = NOW + 10 days * checkout B3 to P3 with a due date = NOW + 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level.
(In reply to Olli-Antti Kivilahti from comment #8) > overdue_notices.pl properly queues letters to koha.message_queue but the > parse_letter() doesn't parse any letter placeholders <<branch.branchname>> > atleast for email and sms transport type. Unsure if this is because of my > merge. Placeholders work when triggering notifications from > check-in/check-out for ex. The placeholder is not branch.branchname but branches.branchname :) > Merge conflict needs to be resolved. Conflict resolved.
Created attachment 23900 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW + 3 days * checkout B2 to P2 with a due date = NOW + 10 days * checkout B3 to P3 with a due date = NOW + 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Just implementing our print message processing and found a nasty bug. I am sending overdue notifications for each letter 1,2,3 via email,print,sms. I have different template configured per transport_type. If a patron doesn't have email configured, instead of getting three messages in the message_queue with their respective letter-templates used, I get only sms and print(using the email-template) So the print is sent using the email template if email address is missing, instead of the print template. This is a big issue since the print templates often follow a very specific eLetter format and must use the proper transport type template.
I just submitted a patch on bug 11696 for this issue.
Yet another bug in overdue_notices.pl. For the overdue letter 2, if there are more than one borrower receiving a overdueletter2 from the same branch via $mtt = print. Only the firstly handled borrower gets his overdue letter, other print letters for the same branch and borrowertype and overdueletternumber are skipped because $print_sent == 1. overdue_notices.pl: 627 => $print_sent = 1 if $mtt eq 'print'; is the culprit, but overdue_notices.pl: 438 => my $print_sent = 0; # We never sent a print notice is instantiated too early, preventing iteration of extra borrowers.
Created attachment 25219 [details] [review] Bug 10832: FIX Some print notices may not be sent If overdues should be sent to some patron (on the same branch), only the first one was notified. This patch fixes this issue.
Created attachment 25223 [details] [review] Bug 10832: FIX Some print notices may not be sent If overdues should be sent to some patron (on the same branch), only the first one was notified. This patch fixes this issue. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Olli-Antti, should this be signed off?
oki
Does not apply anymore on top of 9016. Please rebase.
Created attachment 27468 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW + 3 days * checkout B2 to P2 with a due date = NOW + 10 days * checkout B3 to P3 with a due date = NOW + 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Created attachment 27469 [details] [review] Bug 10832: FIX Some print notices may not be sent If overdues should be sent to some patron (on the same branch), only the first one was notified. This patch fixes this issue. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Last patches fix conflict with bug 11598.
QA: Looking at this one now.
Created attachment 27496 [details] [review] Bug 10832: Multi transport types for overdue notices Test plan: - define some complex overdue rules (tools/overduerules.pl). For example: First overdue from 2 to 5 days by sms and email with letter code L1 Second overdue from 5 to 15 days by email with letter code L2 Third overdue from 15 days by print with letter code L3 - defined a message for each transport type selected (tools/letters.pl). - select 3 patrons (P1, P2, P3) and 3 barcodes (B1, B2, B3). * checkout B1 to P1 with a due date = NOW + 3 days * checkout B2 to P2 with a due date = NOW + 10 days * checkout B3 to P3 with a due date = NOW + 20 days - into the mysql cli, note the value of unsent message: select count(*) from message_queue where status != "send"; - launch the cronjob: perl misc/cronjobs/overdue_notices.pl - retry the previous sql query, you should have X + 4 unsent messages (depending of current checkouts in your DB!). - view all unsent message: select borrowernumber, letter_code, message_transport_type, content from message_queue where status != "send"; You should see: 2 messages for P1, 1 for sms, 1 for email and the letter code L1 1 message for P2, 1 for email and the letter code L2 1 message for P3, 1 for print and the letter code L3 - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. A print notice is generated only 1 time per borrower and per level. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 27497 [details] [review] Bug 10832: FIX Some print notices may not be sent If overdues should be sent to some patron (on the same branch), only the first one was notified. This patch fixes this issue. Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
No circulation PREDUE letter at /usr/share/koha/testclone/C4/Letters.pm line 455 (Similar remark as on report 10845. Listing the mtt would be helpful too.) Passed QA
Created attachment 27498 [details] [review] Bug 10832: Add the MTT in the warn message If no template is defined for a letter and the needed MTT, we should display the MTT.
Pushed to master. Thanks, Jonathan!
Hi, I have a (late) question about this development: >- Specific case: If a user don't have a smsalertnumber and a sms is > required or if a user don't have an email defined and an email is > required, a print notice is generated. > A print notice is generated only 1 time per borrower and per level. Before the MTT patches were pushed there as an email send to the library containing all notices for patrons without email address. Is this still possible now? Is some additional configuration required? I have tested this and I can see the notices show up as 'print' in my message_queue. I think this fallback cannot be avoided, as I haven't set up any notices for print nor checked the print checkbox in notice triggers.
(In reply to Katrin Fischer from comment #29) > Hi, I have a (late) question about this development: > > >- Specific case: If a user don't have a smsalertnumber and a sms is > > required or if a user don't have an email defined and an email is > > required, a print notice is generated. > > A print notice is generated only 1 time per borrower and per level. > > Before the MTT patches were pushed there as an email send to the library > containing all notices for patrons without email address. Is this still > possible now? Is some additional configuration required? > > I have tested this and I can see the notices show up as 'print' in my > message_queue. I think this fallback cannot be avoided, as I haven't set up > any notices for print nor checked the print checkbox in notice triggers. From the commit message: - Specific case: If a user don't have a smsalertnumber and a sms is required or if a user don't have an email defined and an email is required, a print notice is generated. I can provide a patch if everyone agrees on how we should manage this case. Have a look at the wiki page (http://wiki.koha-community.org/wiki/Message_transport_types), we (Olli and me) explained the different behaviors.
We could always catch failed sms'es with a report? Then manually deal with those cases? Or have an extra feature to handle failed message deliveries. Resend/Change MTT/Delete...
(In reply to Jonathan Druart from comment #30) Whaou, this comment was quite stupid, I quoted what you already quoted...
(In reply to Katrin Fischer from comment #29) > Before the MTT patches were pushed there as an email send to the library > containing all notices for patrons without email address. Is this still > possible now? Is some additional configuration required? > > I have tested this and I can see the notices show up as 'print' in my > message_queue. I think this fallback cannot be avoided, as I haven't set up > any notices for print nor checked the print checkbox in notice triggers. I think what you want is to call the gather_print_notices cronjob with the letter_code and the email params (introduced by bug 11603 and/or bug 11678). Like that, you can sent the print notices to 1+ email.
In 3.18 -> if a user don't have an email defined and an email is required and print is not required, a print notice is generated with the content of email. -> if a user don't have an email defined and an email is required and print is required, a print notice is generated with the content of print. Print required ou not not required , we must have a print notice with content of print not content of email with a message_transport_type=print....
(In reply to delaye from comment #34) > In 3.18 > > -> if a user don't have an email defined and an email is > required and print is not required, a print notice is generated with the > content of email. > > -> if a user don't have an email defined and an email is > required and print is required, a print notice is generated with the > content of print. > > Print required ou not not required , we must have a print notice with > content of print not content of email with a message_transport_type=print.... It looks the same as bug 14133.