import error in v6rc2

Hello,

Our R&D Teams are focused on the latest OpenERP version, and this issue does not affect it.

Our policy is to keep the changes applied on stable branches to a minimum, in order to limit the regression risks for customers that are in production. This means that bugs reported on Launchpad are fixed in the trunk branch only by default, even if they were reported against other stable versions.

We stand of course ready to backport the change to stable releases if it has an impact on any customer. In this case please report it to our maintenance team via the OpenERP Publisher's Warranty. They will quickly help solve the issue and backport the fix if needed.

Thank you for your understanding!

This bugreport is really about 6.0rc2, not about 5.0.12, so let's reopen it.

@Nima-k2: for migrating from 5.0 to 6.0 you can try import/export if you only have simple data (e.g contacts or products), but your mileage may vary and this strategy will not work for more complex cases, such as objects with workflow states, etc.

@Olivier Dony :for a more complex case what is the suggested method for migration? database manipulation or somethin?

@Nima-k2:
For more complex migrations, we have been developing a complete incremental migration process, so OpenERP (the Publisher) can take care of migrations automatically as part of the regular Publisher's Warranty contract. This is explained in more details on http://www.openerp.com/services/subscribe-onsite
From what I've heard the migration team will process the first actual customer migrations as of February 2011 (beta tests are already ongoing)

There are also ongoing efforts in the community to develop migration scripts, probably more suited to experienced OpenERP specialists, who are able to diagnose and troubleshoot any data migration/inconsistency issue themselves. I don't know exactly how far these efforts have gone yet, maybe others can comment on this.

Saz confirmed that the issue can be reproduced, so I'm assigning to the framework team for resolution.

Hello Nima,

I have tested your scenario of import data with the latest code and it works fine at my end. I have tried with the both option import compatible, and simple one. Would you please tell me the precise steps or more information of it.

Thanks.

Sorry

Please ignore the comment #6.

Thanks.

Hello,

I tried it, but I can't reproduce this error in any way.

Could you attach as CSV file that produces the error for you? This could help track down the issue...

Thanks!

This can be reproduced with the following:

Create a new database with demo data, load purchases module (or any other module that brings in product data), go to products and export some products with the fields name, default_code and seller_ids. If you try to import the file in question, you will get an error.

As a workaround for the bug, you can change the field name to reflect the actual field in the relation, like my this case seller_ids changes to seller_ids/name and so on.

@Sami Haahtinen : ihave tested that it doesn't work.

Hello,

I have attached the screen shot for list of fields to be exported in csv file with the option import compatible.

Now I am modifying the csv and adding some more rows into it and try to import this file into the new DB but client crashes with the xml rpc lib fault.

Thanks.

Update status/importance according to duplicate bug 712984.

The exposed situation seems not to be a bug in the server directly but is arguably a bit difficult.

In 'import compatible' mode, the client (gtk or web), not the server can choose which fields are exportable or not. In this case, while 'import compatible' is correctly checked, it is still possible to export data that the import mechanism won't be able to process (for good reason, for instance a field is read-only).

One of those reason concerns fields that are relationships to other objects. That is, fields with a '+' in the GUI. The exported value of those field is usually computed from the values of the object it points to. Although it is nice, it is difficult to do the opposite processing: parse a single field and update the corresponding data in the object.

As an example, you can export the 'Contacts' field. Its value will be a concatenation of the street, the contact name and other things. But on the other hand, it is clear that it is not possible to update the individual fields of an Address just by giving a single value.

So the problem is really in the GUI which doesn't really honor what 'import compatible' should mean. A bug was filled against the client to change the situation. Another problem is the lack of thorough checking at import time to report better error messages.

In the mean time, don't export the '+' fields as-is but only their sub-fields.

When modifying an exported csv file to import it after, be sure to not give Database IDs: those can be used if you want to modify the associated data but not to create new data. Database IDs are assigned by the system when data are created. If you need to refer to those data, use a simple ID.