[6.0.2] CSV import auto-detect does not support ":id" headers at client-side
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo GTK Client (MOVED TO GITHUB) |
Incomplete
|
Low
|
OpenERP sa GTK client R&D | ||
Odoo Web Client |
Won't Fix
|
Low
|
OpenERP R&D Web Team |
Bug Description
Hello,
Server: Ubuntu v10.04
Workstation: Windows 7
In V5, it was possible to import via transactional object import (both GTK and web) all files including header line with ":id" or ".id". It seems that in V6 it is not possible anymore, as it accepts only "/id" or "/.id".
This is a quite big regression as we can't use anymore the same file declaration for import via server or client.
Our remark may look trivial, but we try to streamline our data migration processes like all other partners in order to reduce OpenERP costs against competitors. In that context we have developed data migration templates filled by clients. These templates can be used for data loading on server side as well on client side. It was succesful on v5 but no more on v6 due to that issue.
Is there any good reason to block the ".id" and ".id" on client side in V6 ? This issue obliges to define two different templates for server and client import, which has no clear advantage...
Regards,
Bernard
Changed in openobject-server: | |
assignee: | nobody → OpenERP's Framework R&D (openerp-dev-framework) |
importance: | Undecided → Low |
status: | New → Confirmed |
summary: |
- [6.0.2] Regresion v5->V6: client import does not accept ":id" anymore + [6.0.2] CSV import auto-detect does not support ":id" headers at client- + side |
Hello Bernard,
When you say "does not accept", I suppose you mean that auto-detection does recognize it, right? This does does not actually prevent you from uploading the file by specifying the field names manually, normally.
I agree this is not consistent, and is caused by the various patches in 6.0 to improve the client-side import logic (rev 1727 and 1729).
Here are 2 quick and dirty patches (untested) to restore that behavior in a consistent manner (also for translations) in both GTK and Web clients. I will leave the final resolution to the Web and GTK teams.