← Back to team overview

openerp-india team mailing list archive

[Bug 1220726] Re: Generated message reference does not include database identifier

 

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

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/1220726

Title:
  Generated message reference does not include database identifier

Status in OpenERP Addons (modules):
  New

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

  Example:

  References: <4FE8440C.4060809@xxxxxxxx>
  <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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/1220726/+subscriptions


References