Define many recipients on notification email

I need to define many email addresses on recipients (or secondary recipients) field in notification email.
I first thought to define all emails in a single contact mechanisms with comma separator, but it does not work in some email servers for security policies; each email must be an item on the recipients list.

So I’m wondering if it should be considered on the module when extracting email from party/employee/contact mechanism.
Of course I can add more recipients fields if it is not a desired feature/bugfix.

The module supports by default xxx2Many fields and when used it will send the email to each record of the field.

Why you need more recipients? Could you please give more details about the type of recipients that will receive the notification?

Sorry but I don’t see it. Indeed the code is ready to manage many recipients but at the end the recipients field is a Many2One.

Is quite simple: they need to send the message to more than one party email addresses for sales or invoices.
Using the contact defined on document is not enough as there are cases of more than 2 addresses.
Just comment is not a requirement of a single customer, we have several with this situation. But with the trick of comma separate emails the others could work.

You can create a functional One2Many field with all the involved parties and use it for email notification.

If the contact fields on the document are not enought how you know which addresses are related to the parties?

Could you please explain the problems of your customers (and not only how you think it can be solved)?
If you explain the real use case it’s easier to find a solution that works for all.

The addresses are always the same for a given party.

I think I did it … the user needs to send the email message to a set of fixed addresses according to his customer’s demand. This addresses could be personal or generic: p.e sales@mycustomer.com, office@mycustomer.com, john.thesalesman@mycustomer.com, …

Then probably the best option is to extend _get_addresss method of the notifications to return all the email addresses and names where you want to send the notification.

Or to create define a usage on contact mechanism for this use case.

This is what I was implementing before start this thread.

But AFAIK the notification gets only the first contact mechanism of given usage.

Or you can use a single address with a forwarding rule.
One special customer should not increase the complexity the system.

I’m afraid I haven’t explained myself correctly because it is happening with many customers in many deployments.
Indeed we are moving all from electronic_mail to notification_email and we find a few requirements not supported.

Anyway thanks for your comments, finally I extended _get_address to manage email contact mechanism with many addresses separated with comma.

I still find this requirement very strange. Such companies are really not structured at all to have such requirements from their suppliers. And what a waste of attention to send the same automatic email to many person in a company.

I think it is a bad idea because it pervert the design and it will probably break any other module that is using contact mechanism.
I think it is better to add support for relation field pointing to contact mechanism. But it would ignore it if it is not an email and/or its usage is not compatible.

the requirement is from their customers.

Yes it is. Checking some examples I found a case with 9 addresses.

Could you ellaborate please?

If we allow to use contact mechanism relation, you can have a xxx2Many pointing to them as receipt.

Ok, so IIUC you propose to add a relation among contact mechanisms. This sounds great.

Yes but it will require first to implement Issue 9363: Allow contact mechanism as email notification recipients - Tryton issue tracker in order to allow the contact mechanism fields as recipients of the notification.

IMHO it is not a requirement but a complementary feature as contact mechanisms is already managed through party.
But will be great to have such 2 features.

1 Like