Generated message reference does not include database identifier

Bug #1220726 reported by Ronald Portier (Therp)
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
New
Undecided
Unassigned

Bug Description

When OpenERP send out mails it generates an identifying string, adding this to the References message header.

Example:

References: <email address hidden> <1340622576.38-openerp-2-vrs.case@therp-vstro3550>

The string contains a timestamp, a random number, the string 'openerp', a resource id, a model name and a domain. The string is generated by the method:

generate_tracking_message_id in tools.mail.py.

When receiving messages OpenERP decides wether to create a new resource (record), based on the presence or not of this string in the incoming message.

The regular expression used to parse the reference is also defined in mail.py:
297 # Updated in 7.0 to match the model name as well
298 # Typical form of references is <timestamp-openerp-record_id-model_name@domain>
299 # group(1) = the record ID ; group(2) = the model (if any) ; group(3) = the domain
300 reference_re = re.compile("<.*-open(?:object|erp)-(\\d+)(?:-([\w.]+))?.*@(.*)>", re.UNICODE)

In addons/mail/mail_thread.py it is assumed that when this string is present, we have to update an existing record:
 510 # 1. Verify if this is a reply to an existing thread
 511 thread_references = references or in_reply_to
 512 ref_match = thread_references and tools.reference_re.search(thread_references)
 513 if ref_match:
 514 thread_id = int(ref_match.group(1))
 515 model = ref_match.group(2) or model
 516 model_pool = self.pool.get(model)
 517 if thread_id and model and model_pool and model_pool.exists(cr, uid, thread_id) \
 518 and hasattr(model_pool, 'message_update'):
 519 _logger.info('Routing mail from %s to %s with Message-Id %s: direct reply to model: %s, thread_id: %s, cus tom_values: %s, uid: %s',
 520 email_from, email_to, message_id, model, thread_id, custom_values, uid)
 521 return [(model, thread_id, custom_values, uid)]

This breaks down when one company with OpenERP sends a mail (for instance a sales invoice), to another company with OpenERP. As the reference does not contain a unique identifier for each database instance, it might be possible to link a message to a completely wrong object.

Fortunately the message I used for testing referred to a model that did not exist in the receiving database.

Therefore: when sending out a message with a reference, a unique and unmodifiable unique ID for the database should be included in the reference. And when receiving mails only references including this unique ID should be used to link to existing model records.

Of course there is the question what to do with messages send out in the past, that did not include this unique ID.

And the question is how to generate and where to store this unique ID.

But in principle this is how the problem should be solved in my opinion.

Just to prevent others waisting their time: each postgres database has a unique identifier. But there is no easy and OS independent way to retrieve this.

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

One other remark:

when an incoming mail server (fetchmail) configuration is tied to a certain model, it should not handle messages that have a reference to another model.

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

Hi Ronald,

I'm removing OCB-addons as an affected project for this bug as per project policy. Of course the bug affects ocb-addons/7.0 by definition as well as openobject-addons but we only want to track bugs that we fix in OCB-specific changes. Therefore, you should only add bugs to the project that you are going to propose a solution for.

Thanks,
Stefan.

no longer affects: ocb-addons
no longer affects: ocb-addons/7.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.