c2c-oerpscenario team mailing list archive

[Raphaël Valyi - http://www.akretion.com <685318@xxxxxxxxxxxxxxxxxx>]

>
> [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 ;)


xrg, this is achieved in base_external_referentials by extending
ir_model_data in a way that you can a list of "external referential" that
could me just OpenERP modules but actually have a few more properties such
as URL, credentials, mappings methods from one referential to another..
And in ir_model_data, we use the "name" field with ext/ref_name where
ref_name is the name of that external referential.

Indeed that wouldn't be stupid to take some of the
base_external_referentials methods or even take it all and promote it to the
core. This is indeed my suggestion as I would very much prefer all those new
connectors (Salesforce, quickbooks, sage and all) use that common
infrastructure rather than each re-invent their own little hacks to map ids
and fields between referentials.

-- 
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.