`force_send` is an option in `mail` core module
that allows to send an email immediately.
Handling the message w/ digest is wrong and in any case
we gonna have a digest w/out the message inside it
since is going to be deleted right after send.
A typical use case is the notification sent to new followers.
- Adds is_synced field to track whether a dynamic list has unsynced
changes or not so the user is aware that the definitive number of
contacts is yet to be determined.
- It fixes an issue that made impossible deleting a res.partner filter
when a list had use it to filter contacts.
- It also shows only the filters available for the user (shared and
belonging to self).
we need to save the complete list of partners because
_message_notification_recipients builds recipients
grouped by users groups. Thus get_additional_footer would get a
partial list of recipients
On our server,
queries based on "mail_tracking_event"."tracking_email_id" improved from 501,924 ms to 1,840 ms
queries based on "mail_tracking_email"."mail_message_id" improved from 167,436 ms to 3,223 ms
The last ones are run several times when a thread has many messages
* [FIX+IMP] mass_mailing_list_dynamic: tests, icons, filters...
* Brand new icon
* Added feature of loading an existing filter as criteria
* Tests as SavepointCase for optimizing times
* Tests in post-install for avoiding errors on res.partner not null constraints
when several modules added them.
* Updated documentation.
* Fix mock in test for not commiting test data.
* [FIX] mass_mailing_list_dynamic: Wasn't able to create contacts in fully synced lists
Syncing context was being set in the wrong object. Added to test too.
* [FIX] mass_mailing_list_dynamic: Allow to write back vals from res.partner
Module mass_mailing_partner writes back certain values from partner to
mass_mailing_contact. Module should allow that write operation.
* [ADD] mass_mailing_resend
Resend mass mailings
====================
A frequent need for users of mass mailings is to resend one mailing that has
already been sent in the past to new recipients that haven't received yet that
mail. But the problem is to know which are the applicable ones.
Odoo already includes a method in its mass mailing logic that avoids to resend
the same mail 2 times for one mass mailing, and for v9, there was a trick that
allows to modify the state of a mass mailing from kanban view, covering the
need.
But now on v10 both status bar in form view and dragging between states in
kanban are not allowed.
This module introduces a button to restart a mass mailing to draft state,
allowing you to reevaluate the sending domain or list for performing again
the mailing.
Usage
=====
* Go to *Mass mailing > Mailings > Mass Mailings*.
* Click on one record that is done or create a new one and send it.
* You will see a button called "Resend".
* If you click on it, mass mailing will be set to Draft again.
Known issues / Roadmap
======================
* Add an indicator / filter for knowing resent mailings.
* Include information on the number of new recipients to be sent on the
resending (through `get_remaining_recipients` method).
Without this patch, users without access to reading and editing mass mailing contact records are now unable to change a partner's name or email. They'd recieve an exception such as:
AccessError: Sorry, you are not allowed to access this document. Only users with the following access level are currently allowed to do that:
- Mass Mailing/User
(Document model: mail.mass_mailing.contact)
Restrictive ACLs shouldn't restrict normal user operation nor DB consistency, so using sudo mode now and testing behavior.
When this method is called without an event (a.k.a. `event=None`), this method produces the following error:
```
Traceback (most recent call last):
File "/opt/odoo/auto/addons/mail/models/mail_mail.py", line 278, in send
res = IrMailServer.send_email(msg, mail_server_id=mail.mail_server_id.id)
File "/opt/odoo/auto/addons/mail_tracking/models/ir_mail_server.py", line 88, in send_email
tracking_email.smtp_error(self, smtp_server_used, e)
File "/opt/odoo/auto/addons/mail_tracking/models/mail_tracking_email.py", line 213, in smtp_error
self.sudo()._partners_email_bounced_set('error')
File "/opt/odoo/auto/addons/mail_tracking/models/mail_tracking_email.py", line 203, in
_partners_email_bounced_set
]).email_bounced_set(self, reason, event=event)
File "/opt/odoo/auto/addons/mail_tracking_mailgun/models/res_partner.py", line 22, in
email_bounced_set
self._email_bounced_set(reason, event)
File "/opt/odoo/auto/addons/mail_tracking_mailgun/models/res_partner.py", line 33, in
_email_bounced_set
event['Message-Id'] or '') TypeError: 'NoneType' object has no attribute '__getitem__'
```
So, we now assume we do not always have an event.
When creating digest records within the context of mail composer
(and possibly other contexts) you'll have a `default_template_id`
key in the context which is going to override our safe default.
This is going to break email generation because the template
will be completely wrong and unpredictable. Lesson learned :)
Pedro M. Baeza
Simone Orsi
OCA Git Bot
eLBati
David
Alexandre Fayolle
OCA Transbot
Daniel Reis
Jairo Llopis
Guewen Baconnier