Currently except for messages originating from the patron we do not set a reply_address when enqueuing letters, git grep reply_address If no reply address is specified when we are sending the messages we use the patron's library's address: 1325 sub _send_message_by_email { ... 1363 if ($patron) { 1364 $library = $patron->library; 1365 $branch_email = $library->from_email_address; 1366 $branch_replyto = $library->branchreplyto; 1367 $branch_returnpath = $library->branchreturnpath; 1368 } ... 1393 reply_to => $message->{'reply_address'} || $branch_replyto, This means that when an overdue is sent by the issuing library, replies go to the patron's branch
Do you mean when editing a notice template?
(In reply to Jonathan Druart from comment #1) > Do you mean when editing a notice template? That would be interesting, I was thinking a system preference for using the patron library, or the notice branch as the default. Or adding an option to scripts that generate notices, i.e.: perl misc/cronjobs/overdue_notices.pl --reply_to item-homebranch
Maybe we should consider the overdues one as a bug first? I think we should match the reply to to the address we are sending the notice from in this case and possible others as a default. I believe using a pref would not work for all notices. For example DUEDGST are always sent from the patron's library and can contain information about issues from multiple libraries, so any other setting makes no sense. I am also not sure we can fit a general solution in the notices tool well - maybe we should look at some more use cases first to see where we are going there. But I think fixing the overdues bug first would be most important.
(In reply to Katrin Fischer from comment #3) > Maybe we should consider the overdues one as a bug first? > > I think we should match the reply to to the address we are sending the > notice from in this case and possible others as a default. > > I believe using a pref would not work for all notices. For example DUEDGST > are always sent from the patron's library and can contain information about > issues from multiple libraries, so any other setting makes no sense. > > I am also not sure we can fit a general solution in the notices tool well - > maybe we should look at some more use cases first to see where we are going > there. But I think fixing the overdues bug first would be most important. I think in cases where a digest is used, if notices are coming from only one library, then it could default to what the other notices are set to use for the reply to address. However, if it is a mix of libraries, then perhaps it could be preference options of A) patron home branch, B) first library in the list, C) the library referenced the most, or D) use a noreply@patronhomebranchdomain.com address (where the patronhomebranchdomain.com is actually their home branch's domain).
Just nudging this bug a little. I'll bring it to the attention of people in slack so they can add some input.
I'd like to see options in the message template. Something like a series of radio buttons that indicate Reply to address for this message: System e-mail address (based on KohaAdminEmailAddress) System Replyto address (based on ReplytoDefault) Transacting library's e-mail address (based on library's Reply-To) Borrower home library e-mail address (based on library's Reply-To) Other (with an option to enter an e-mail address) And there might be some other options I haven't thought of yet.
(In reply to George Williams (NEKLS) from comment #6) > I'd like to see options in the message template. Something like a series of > radio buttons that indicate > > Reply to address for this message: > > System e-mail address (based on KohaAdminEmailAddress) > System Replyto address (based on ReplytoDefault) > Transacting library's e-mail address (based on library's Reply-To) > Borrower home library e-mail address (based on library's Reply-To) > Other (with an option to enter an e-mail address) > > And there might be some other options I haven't thought of yet. Should this be an option on each template, or just defaults, or just global? We should have this set of options for both individual e-mails AND digest e-mails, in my opinion, so I guess to answer my question, it should be on each template.