Can't import-update in 6.1 with web client

[YannickB (YOLO consulting)]

Hi everyone,

I just begin to work with the 6.1, great release, but something went wrong for me.

I tried to import some csv data with the web client. No problem, it worked. But then I tried to update the data with a column database_id (.id) .

Unfortunately, it seems the web client isn't able to recognize the .id column. And so, instead of updating the records, it created new ones.

No problem with the heavy client, .id works.

This is a important feature which is now missing on the web client, I think it should be fix asap.

Regards,
Yannick.

[Vishal Parmar(Open ERP) (vpa-openerp)]

Hello YannickB,

I have checked in latest updated code of 6.1 and it's work. I am not getting exactly you point from where you updated the data. I have attached screenshot would you please check it and informed us where you faced the problem with related steps,video.

Thanks and waiting for your reply.

[YannickB (YOLO consulting) (yannick-buron)]

Hi,

No you didn't understand. I'm not talking of an id column in the csv file but .id (note the dot) column.

The difference is .id is in fact the database_id, where id is the openerp id (used for example in xml file of the module).

Ex :
id = base.res_partner_agrolait
.id (database_id) = 3

In V6, if we used the .id column in a csv file we updated the record instead of creating a new one. This still work on the heavy client.

Now it seems that the web client can't recognize the .id column, and so we have no way to update record with csv anymore.

[Vishal Parmar(Open ERP) (vpa-openerp)]

Hello YannickB,

I agree with you.

.id(dDatabase Id) is work on heavy client but not in web.

Thanks.

[YannickB (YOLO consulting) (yannick-buron)]

Hi,

We have this problem since some month now, and this is really beginning to be a troublesome one. Since the heavy client is lesser supported now, we begin to have case where we just can't make mass modification with CSV without using an ETL.

This is really a big regression, I don't think we should wait longer any more. I respectfully suggest to up the priority of the bug report.

Regards,
Yannick.

[Olivier Dony (Odoo) (odo-openerp)]

Hello Yannick,

The support for database ID has been hidden in the web client because it was confusing users, being shown next to the external ID ("openerp ID" as you call it, e.g. base.res_partner_agrolait). It is also not portable across databases, and therefore not recommended.
It was useful for performing local batch updates, but in fact OpenERP 6.1 comes with a feature that makes it unnecessary: when you export the regular "id" field, a new external ID is created on the fly for records that do not have one. So when you want to do a batch local update, just export the records to update as CSV, being sure to include the "id" column, and you will be able to reimport it back after modification, without creating duplicate records.
Basically we do not want to expose database IDs via CSV anymore, as they can be replaced by equivalent external IDs without any loss of functionality.

I think this provides a workable solution for everyone, while making the interface less confusing due to the presence of multiple ID fields with different semantics.
As for the GTK client, usability is not one of our priorities for it, so it was simply not updated to hide the database ID field.

I'm going to change the status of this bug to "Won't Fix", as we really would like to avoid re-introducing this technical (and now basically useless) field in the UI. Do not hesitate to reply if you think the external ID alternative will not work for you.

[YannickB (YOLO consulting) (yannick-buron)]

Ok, now I understand why you did that.

There is still something that bother me through. With the ETL Pentaho Kettle, I often read the id in the database and then use it to update the record in OpenERP, this is so really helpful.

Unfortunately, the "long id" like __export__.res_partner_31 or base.res_partner_agrolait isn't stored in the database. I can't even guess it (for exemple '__export__.res_partner_' + DB_ID) if doesn't work.

I understand the confuse from having two ID. In this cas, I really strongly suggest that both id should be recognized at the import. This way we could continue to use either long id or database id.

This is really important, I don't think I'm the only one to work directly with the database for reading access.

[Réal Carbonneau (real-carbonneau)]

Just to note that the loss of the "Database ID" field is a major regression in my opinion also. Even with much effort I have not been able to get a working Pricelist Version upload via the "External ID" method, however, the previous file still works using the GTK GUI.

Using a fresh export as a base to add a few new pricing rules to a Pricelist Version, I get the following error: The import failed due to:Error during import: Line 3 : AccessError
One of the records you are trying to modify has already been deleted (Document type: Pricelist item).

I am not looking for a solution to this error under the current bug, however, it is just to demonstrate that the regression is significant. I have tried many other variations without any success.