Project

General

Profile

Actions
Copy link

Bug #12155

closed

Setting email_reply_address is not used without restart of Foreman

Added by Bryan Kearney about 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Stephen Benjamin
Category:
E-Mail
Target version:
1.10.1
Difficulty:
Triaged:
Bugzilla link:
1271129
Pull request:
https://github.com/theforeman/foreman/pull/2819
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1271129
Description of problem:
Changing the setting email_reply_address the new value is not used until Foreman is restarted

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Change the email_reply_address setting to foobar
2. Trigger a mail sending
3.

Actual results:
The from address is still using the original from address and not the updated foobar

Expected results:
Mail from address is changed to foobar

Additional info:

Actions
Copy link
 #1

Updated by The Foreman Bot about 9 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/2819 added
  • Pull request deleted ()
Actions
Copy link
 #2

Updated by Anonymous about 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions
Copy link
 #3

Updated by Dominic Cleal about 9 years ago

  • Assignee set to Stephen Benjamin
  • Translation missing: en.field_release set to 104
Actions
Copy link
 #4

Updated by Stephen Benjamin about 9 years ago

@Dominic - Be aware this commit removes a deprecation that was targetted for removal in 1.11 not 1.10

Actions
Copy link
 #5

Updated by Dominic Cleal about 9 years ago

Stephen Benjamin wrote:

@Dominic - Be aware this commit removes a deprecation that was targetted for removal in 1.11 not 1.10

Thanks for the heads up, but it doesn't look like it's in the final develop commit.

It looks like what happened is that you removed it in your PR, as it was based on an older parent commit (baaf6b4), but since we had already removed it in the newer c1755e0, the actual commit that Daniel merged to develop didn't contain the deprecation removal proposed in the PR. The git 3-way merge process must have skipped over it as it had already been done.

Actions
Copy link
 #6

Updated by Stephen Benjamin about 9 years ago

Oh weird, thanks, I wish GitHub was more explicit in the PR that it would need a 3-way merge to merge it.

Actions
Copy link

Also available in: Atom PDF