Summary: | Overdue notices reply-to email address of a branch not respected | ||
---|---|---|---|
Product: | Koha | Reporter: | Nason Bimbe <nason.bimbe> |
Component: | Notices | Assignee: | Katrin Fischer <katrin.fischer> |
Status: | CLOSED FIXED | QA Contact: | Martin Renvoize (ashimema) <martin.renvoize> |
Severity: | normal | ||
Priority: | P5 - low | CC: | lucas, martin.renvoize, victor |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
22.11.00,22.05.06,21.11.12
|
|
Circulation function: | |||
Attachments: |
Bug 31281: Use correct reply-to email when sending overdue mails
Bug 31281: Use correct reply-to email when sending overdue mails |
Description
Nason Bimbe
2022-08-02 10:42:57 UTC
I recenlty tested this similarly on master and there the correct reply-to was used (but I was missing Sender/return-path). How are you running the overdue notices script? (parameters) How are your overdue notice triggers set up? (do you use a default one or only branch specific?) The cron job is as follows $KOHA_CRON_PATH/automatic_renewals.pl -c --send-notices The Triggers are branch specific. Here is the complete set of Cron jobs as set up (Auto renew, fine, overdue notice) $KOHA_CRON_PATH/automatic_renewals.pl -c --send-notices; $KOHA_CRON_PATH/fines.pl; $KOHA_CRON_PATH/overdue_notices.pl -t --frombranch item-homebranch I think I've found it. overdue notices uses EnqueueLetter to write the letter to the message_queue: C4::Letters::EnqueueLetter( { letter => $letter, borrowernumber => $borrowernumber, message_transport_type => $effective_mtt, from_address => $admin_email_address, to_address => join(',', @emails_to_use), } Reading the POD for EnqueueLetter this stands out: * reply_address - optional; The reply address for the notice, defaults to patron->library->reply_to So as we are not supplying the address, it would use the reply-to address of the patron's homebranch. Created attachment 138760 [details] [review] Bug 31281: Use correct reply-to email when sending overdue mails Overdue emails are either sent from the issuing or the home library of an item. We never use the patron's home library, so the reply-to address must explicitly be set in EnqueueLetter. To test: - Set up 2 branches (A and B) with different email addresses. - Set up an SMTP server for each to use - Set up an overdue notice trigger for the patron category you'll use First letter: 1 day delay, any notice - Check out an item with home branch B to a patron from A - Run the the script with: overdue_notices.pl -t --frombranch item-homebranch overdue_notices.pl -t --frombranch item-issuebranch - Confirm for each setting that the correct email headers have been used. You can see the reply-to address and to-address in the message queue: SELECT * FROM message_queue; Created attachment 139016 [details] [review] Bug 31281: Use correct reply-to email when sending overdue mails Overdue emails are either sent from the issuing or the home library of an item. We never use the patron's home library, so the reply-to address must explicitly be set in EnqueueLetter. To test: - Set up 2 branches (A and B) with different email addresses. - Set up an SMTP server for each to use - Set up an overdue notice trigger for the patron category you'll use First letter: 1 day delay, any notice - Check out an item with home branch B to a patron from A - Run the the script with: overdue_notices.pl -t --frombranch item-homebranch overdue_notices.pl -t --frombranch item-issuebranch - Confirm for each setting that the correct email headers have been used. You can see the reply-to address and to-address in the message queue: SELECT * FROM message_queue; Signed-off-by: Nason Bimbe <nason.bimbe@ptfs-europe.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Tested and signed off by Nason, and then QA'd by myself. Working great and fixes the problem properly. Passing QA Thanks :) Pushed to master for 22.11. Nice work everyone, thanks! Can we get this one backported, please? (In reply to Martin Renvoize from comment #11) > Can we get this one backported, please? Backported to 22.05.x for 22.05.06 Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed. Nothing to document it seems, marking resolved. Hmm, this seems to have jumped an rmaint.. this is probably a decent candidate for 21.11.x ? No worries, I picked it from 21.11.x so it didn't jump. Arthur is experimenting to not update the ticket until the very release date. Then it is possible to use the scripts in release-tools to mass-update the bugs included in the release without taking the risks of forgetting one. I feel that can cause issues as one does not subscribe to the tickets and will miss a regression uncovered and request to revert. And people wouldn't even make the request (in-ticket or via direct email) to revert if there is no message from the RMaint that they backported it. I agree it makes things a bit easier if we see right away if something has already been picked. Thanks! Pushed to 21.11 for 21.11.12 |