Bug 31281 - Overdue notices reply-to email address of a branch not respected
Summary: Overdue notices reply-to email address of a branch not respected
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Katrin Fischer
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-02 10:42 UTC by Nason Bimbe
Modified: 2023-06-08 22:26 UTC (History)
3 users (show)

See Also:
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


Attachments
Bug 31281: Use correct reply-to email when sending overdue mails (1.81 KB, patch)
2022-08-07 16:24 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 31281: Use correct reply-to email when sending overdue mails (1.93 KB, patch)
2022-08-11 11:22 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nason Bimbe 2022-08-02 10:42:57 UTC
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
Comment 1 Katrin Fischer 2022-08-02 10:50: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?)
Comment 2 Nason Bimbe 2022-08-04 15:37:20 UTC
The cron job is as follows
$KOHA_CRON_PATH/automatic_renewals.pl -c --send-notices

The Triggers are branch specific.
Comment 3 Nason Bimbe 2022-08-04 18:33:14 UTC
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
Comment 4 Katrin Fischer 2022-08-07 13:58:11 UTC
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.
Comment 5 Katrin Fischer 2022-08-07 16:24:24 UTC
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;
Comment 6 Martin Renvoize 2022-08-11 11:22:48 UTC
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>
Comment 7 Martin Renvoize 2022-08-11 11:24:15 UTC
Tested and signed off by Nason, and then QA'd by myself.
Comment 8 Martin Renvoize 2022-08-11 11:24:32 UTC
Working great and fixes the problem properly.

Passing QA
Comment 9 Katrin Fischer 2022-08-11 13:10:13 UTC
Thanks :)
Comment 10 Tomás Cohen Arazi 2022-08-16 12:20:39 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!
Comment 11 Martin Renvoize 2022-09-08 08:48:33 UTC
Can we get this one backported, please?
Comment 12 Katrin Fischer 2022-09-08 09:56:18 UTC
(In reply to Martin Renvoize from comment #11)
> Can we get this one backported, please?
Comment 13 Lucas Gass 2022-09-30 22:58:26 UTC
Backported to 22.05.x for 22.05.06
Comment 14 Victor Grousset/tuxayo 2022-10-16 16:02:51 UTC
Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed.

Nothing to document it seems, marking resolved.
Comment 15 Martin Renvoize 2022-10-17 08:25:28 UTC
Hmm, this seems to have jumped an rmaint.. this is probably a decent candidate for 21.11.x ?
Comment 16 Victor Grousset/tuxayo 2022-10-18 03:44:38 UTC
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.
Comment 17 Katrin Fischer 2022-10-18 06:35:08 UTC
I agree it makes things a  bit easier if we see right away if something has already been picked.
Comment 18 Arthur Suzuki 2022-10-22 22:09:33 UTC
Thanks!

Pushed to 21.11 for 21.11.12