matomo-org / matomo

Empowering People Ethically with the leading open source alternative to Google Analytics that gives you full control over your data. Matomo lets you easily collect data from websites & apps and visualise this data and extract insights. Privacy is built-in. Liberating Web Analytics. Star us on Github? +1. And we love Pull Requests!
https://matomo.org/
GNU General Public License v3.0
19.67k stars 2.62k forks source link

Custom email-addresses for sending email reports #20968

Open atom-box opened 1 year ago

atom-box commented 1 year ago

Create a switch statement of some kind so the emails can be tied to the site id.

Users of example1.com and example2.com would have a better of experience if they received email that came from those two domains. Currently we can only send emails from our single global domain matomostats.example.com.

From the original user email we received today:

For both of our sites we send email reports to clients and partners. They are all being sent from info@ABC.com. I don't think there is a way to configure it in a way that allows different addresses for different site id's, right? The idea it to be able to send reports for WXYZ.com via info@WXYZ.com and reports for ABC.com via info@ABC.com

sgiehl commented 1 year ago

We could in theory allow to overwrite the noreply_email_address and contact_email_address in General config on a per site config (e.g. General_1), but that might require some refactorings, as the current site might not be passed through the code when sending out emails.

michalkleiner commented 1 year ago

Or add site related email via the settings in the admin and if none is provided, fallback to the config one?

Stan-vw commented 1 year ago

If I read correctly the ticket is about the email we are sending it from, not the reply-to address. Some thoughts on either:

Perhaps the devs can give a better indication of how hard/achievable these options are.

sgiehl commented 1 year ago

We currently have the following configurations in our config ini file that are relevant for sending scheduled reports:

[General]

; standard email address displayed when sending emails
noreply_email_address = "noreply@{DOMAIN}"

; standard email name displayed when sending emails. If not set, a default name will be used.
noreply_email_name = ""

; using to set reply_to in reports e-mail to login of report creator
scheduled_reports_replyto_is_user_email_and_alias = 0

The configurations for noreply_email_* will be used as from for the emails. So it is already possible to configure that globally. The request here is to make that configurable on a per site base.

This would in theory be possible to use an already implemented way to configure stuff for sites specific. Some configurations already allow to set something like

[General_1]

config=value

This would e.g. configure something for site with id 1 only. But our code using this configuration needs to be adjusted to make this possible, as the current site id needs to be available at the point where the configuration is read. This is currently not the case for emails in general and would need to be adjusted.

heurteph-ei commented 1 year ago

The best could be also making this configurable in the Admin > Measurables > Manage settings...

sgiehl commented 1 year ago

The best could be also making this configurable in the Admin > Measurables > Manage settings...

Actually I'm not sure about that. I doubt many people would actually use this and adding more and more options to the UI might only make it less usable.

heurteph-ei commented 1 year ago

In the other hand, in my opinion, this feature (set custom email for each measurable) would be for administrators that manage analytics for many different clients, and going to the config file each time you add a new client is not really user friendly... 🤔

sgiehl commented 1 year ago

I agree with that for a reply-to header. But with changing the from header you can easily cause emails not to be delivered or to be caught in spam filters if they don't match the mail server they are sent from, so it could also be risky to give any site admin the possibility to do so.

Stan-vw commented 1 year ago

Perhaps we should only make this available for superusers (in the UI) and also explain the downside in the inline helptext?