Before this commit, some methods with views crashes trying to
process 'failed_message_ids' field.
After this commit the 'failed_message_ids' field description
is properly generated.
Catching this event as a bounce leads quite often to false bounces, like
in the cases the error is due to our own instance SMTP errors. Errors
like a too large message should no bounce a thread's recipients as the
problem isn't in the recipients side but ours.
We leave anyway some true positives aside (like in the case of malformed
email addresses). We should be able to detect and fix those anyway.
- Any model inheriting from mail.thread will have a filter available to
obtain records with errors in their messages trackings.
- The messages can be marked as done to avoid false positives when the
issues are solved.
- Partner get bounced when his associated email is in a hard bounced
tracking. It didn't matter if the hard bounce event was solved in that
recipient later and leaded to an increasing number of false positives.
- We also use the email_bounced_set() method to get the whole bounce
info in case positive.
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