The overdue notification email is sent from the correct email address as set up for the branch, however the reply-to email address though set for the branch is not the one used. The email has reply-to address of a different branch and not even the default one as set up in system preferences. Below is set up (however I have renamed the branches and email addresses for the purpose of this bug report). So what happened is the overdue notification was sent using LibraryB email address however the reply-to email address on the notification is the reply-to email address of LibraryA instead of LibraryB one. This is on Koha 21.11.05.000 LibraryA settings Email: librarya@mlibary.whatever Reply-To: librarya@mlibrary.whatever Return-Path: librarya@mlibrary.whatever LibraryA settings Email: libraryb@mlibary.whatever Reply-To: libraryb@mlibrary.whatever Return-Path: libraryb@mlibrary.whatever LibraryC settings Email: libraryc@mlibary.whatever Reply-To: libraryc@mlibrary.whatever Return-Path: libraryc@mlibrary.whatever SysPref setting: KohaAdminEmailAddress: library@library.whatever ReplytoDefault: library@library.whatever
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