Technical mailing list archives

Re: Email templates and auto_delete flag inconsistency

by Olivier Dony <> - 08/04/2014 08:46:25
On 08/01/2014 10:42 PM, Maxim Litnitskiy wrote:
> As far as I understand the problem is in
>          _columns = {
>              '*mail_message_id': fields.many2one('mail.message', 'Message',
>     required=True, ondelete='cascade'), *

I think you're reading it wrong: ondelete='cascade' means the mail.mail entries 
corresponding to a mail.message record are deleted when the message gets 
deleted, *not* the other way around. This is correct and inevitable since a 
mail.mail *inherits* mail.message. It only contains partial information and 
does not make sense without its parent message. So the cascading does not go in 
the other direction (but something else can do this, read below).

A mail.message contains the master data, while it's (children) mail.mail 
contain the technical data for delivering the message to its intended 
recipient. A mail.mail mostly represents a "queue item" while the message is 
being delivered, and can be safely deleted afterwards unless you need that 
low-level info.

> Why  delete messages when deleting email?

The system deletes a mail.mail after sending it (auto-delete), but it normally 
preserves its parent mail.message (that contains everything anyway: the message 
body, recipients, date, message-id, etc.)

The reason you see a difference between sending an email from a server action 
versus manually is because the system will delete the parent mail.message after 
sending only when it detects it as a purely message. This means it was created 
only as a side-effect of creating a mail.mail (to hold the data), not the other 
way around. It will therefore not appear in the history of any document, and 
would become /unreachable/ after being sent.
See the mail.mail.unlink() here:

So you should probably be doing something different in your server actions:
  - render the email template and then post it properly on the related document 
(e.g. the lead) by using the message_post() method. This will record it in the 
history of the document, and thus preserve the mail.message even if the 
mail.mail is auto-deleted.
  - alternatively, if you don't want that email to be visible in the history, 
but still want replies to end up in the right place, make sure you send the 
email via the email.template.send_mail() method, so the Message-Id field 
contains the reference to the record. In that case message_route() should match 
it when processing replies, and route it correctly, see step 2: 
(this is a somewhat brittle legacy feature that may not be kept in future version)