c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

On Tuesday 07 June 2011, you wrote:
> "to be unique per *module*, not per module + model"
> 
> Guys, we had that kind of issue with the base_external_referentials module.
> The way we fixed it is that we force the "XML id" to be actually the
> concatenation of he model name and the id, like "product_product/42" then
> you will have unique XML ids by module again. If that helps...


Well, this is pretty much what core openerp does, too.

ir.model.data is supposed to map ('module', 'name') => ('model',
'res_id') [1]

The convention is that 'name' contains some hint about the 'model', so that we 
don't end up with conflicting names. So, you will notice that names are like 
'product_product_42' etc.. not 'record_42' that would produce the issue 
discussed.

IMHO we need not change anything to /enforce/ this convention. We just keep 
following it in the way we generate the names.


[1] Raphael, I really support the idea of adding a 'type' field in core, too, 
in order to distinguish between 'xml' entries and any other of 3rd party 
connectors ;)

-- 
Say NO to spam and viruses. Stop using Microsoft Windows!

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/685318

Title:
  Import: incoherence due to duplicate id in ir.model.data

Status in OpenERP Server:
  Invalid

Bug description:
  Note this bug has been discovered at openERP premises (with Naajla and
  Jacques-Etienne) during a support service but they asked me to post in
  Launchpad to be sure it will be followed and resolved.

  Potentially this issue remains also on the V6 and should be checked in
  this environment also...

  
  I have built a import module using CSV files but after the module installation I had inconsistencies in the uploaded data (ie wrong users assigned to project or tasks).

  The reason of that was the fact that I was using same id for user and employee (ie user with ID 'CB' and employee with an ID also named 'CB'); the impact was:
  - the system deleted some entries in ir.model.data related to users
  - the user assignment in table loaded was incorrect in the objects (other users were assigned in analytic accounts/projects/task than the ones mentioned in the csv files

  So, the issue seems to be that the import functions don't support same
  ids (field "Name" in ir.model.data) used for different objects (field
  "model" in ir.model.data)

  This should be solved if the table keys used for reading ir.model.data
  include fields "Name", "Module" but also the "Model" field that is not
  included in the read key.