(Enhancement) Apply "Mailer is owner" only when the email template has no value specified for "from name" and "from email"

[albanleandri]

What type of report is this:

Q	A
Bug report?
Feature request?
Enhancement?	X

Description:

When "Mailer is owner" is enabled but values are specified in the template for "from name" and "from email", then these values should override the contact's owner's name & email when an email is sent to this contact.

Today (2.12.2), this behavior doesn't exists and "Mailer is owner" will force against whatever was specified as from name and from email in the template.

"Mailer is owner" is already a great feature, but this simple enhancement would allow a superior control regarding what templates are allowed to take advantage of it.

Use case : Some marketing email are better sent on the behalf of a brand (like newsletters or product updates), while some others are more efficient when they are from a person of your organization (usage of {signature}, SDRs emails, onboarding emails, etc...).

[dscotese]

I'm glad you found this. The problem I have with it is that what I consider to be a "bug" is anything the software does that is different from the user's intent, which I believe raises the priority of fixing it. Perhaps the following will convince you to re-open #5954 or update this issue so that it gets fixed sooner:

Steps to reproduce:

1. Send an email as an existing contact with the "Mailer is Owner" setting ON and with a setting in "Send email as."
2. Note that the email does NOT come from the setting you specified in "Send email as"

Log errors:

mautic.ERROR: [MAIL ERROR] { "errors": [ { "message": "Invalid domain", "description": "Unconfigured Sending Domain ", "code": "7001" } ] } Log data: !! { "errors": [ { "message": "Invalid domain", "description": "Unconfigured Sending Domain ", "code": "7001" } ] } (code: 0) (send); [email addresses]

[jwall-adwerx]

+1 for this.

It's a bad user experience to receive something akin to a product update email from a 1:1 person, and having the ability to override using the "Send email as" setting seems like it'd be a big win.

[RCheesley]

Hi there, as we are only providing fixes for Mautic 3.x going forward, can you confirm if this continues in Mautic 3.0.1?
Thanks!

[blueflamexr]

Hi there, as we are only providing fixes for Mautic 3.x going forward, can you confirm if this continues in Mautic 3.0.1?
Thanks!

+1 for this. I agree that the "Mailer is Owner" should be overridden by the "From name" and "From address" if these are configured in the email. Otherwise, fall back to the Mailer is Owner (if that setting is turned on).

Yes, I can also confirm that this is still an in improvement that is needed in 3.0.2.

Thanks!

[RCheesley]

@albanleandri @blueflamexr I believe that this is resolved by this PR: #6071 - can you test and provide feedback so we can merge it in 3.3?

[atowne-mautic]

I have a question about the implementation of this feature. #6071 (also in 3.3.0-rc) enables the Mailer is Owner option for individual emails, which is great. But with that feature, I don't anyone actually wants this one.

Doesn't it actually make more sense to have Mailer Is Owner override the from name/email address if an owner exists? That way, you can turn Mailer Is Owner on for a specific email and make an email look like it's more of a 1:1 email and still have a fallback in case an owner isn't assigned. If you don't want to make it look like a 1:1 email for anybody, just turn Mailer Is Owner off for that email.

If I'm reading this correctly, if this gets released then users won't be able to turn Mailer Is Owner on for a specific email and have a fallback address that's different from the default in Configuration > Email Settings.

Without #6071, this issue makes a whole lot more sense because you'd want to override the default for the instance on some emails. Acquia has had the Mailer is Owner option on individual emails for a while, and it's been a great improvement for customers that want to make some, but not all, emails look like they're 1:1.

@npracht @RCheesley want to make sure you see this before 3.3.0 goes further than RC (edit: Alan just clarified for me that this was closed without being merged - which is good as only #6071 should be released and not this one)

[RCheesley]

@atowne-mautic this was an issue, not a pull request, so there should not be any problems!