c2c-oerpscenario team mailing list archive

[Graeme Gellatly <787256@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

There are a few strands to this.  Some I can't confirm except to say
they occur on my machine.  I'm not even sure what the bug is I'm
reporting.

1. If the relative path of a symlink includes a hyphen then I think the
import doesn't work.  It chucks a no reference error in the client.  On
checking, this is because there are no entries in ir.model.data when
_get_id is called, the code excepts, silently passes and continues.
Often this means the error at the end is in no way related to the actual
error, as it excepts all the way through, but doesn't raise immediately
so the exception gets overwritten.  I think the csv importer deals with
it fine, so when debugging you see the right lines in the right place.
I think the issue might be where ir.model.data gets populated.  I seem
to remember that xml has an issue with hyphens from when installing the
bzr-xmloutput plugin for bazaar where you need to rename the directory
with an underscore.

2. Upon doing a number of things, like renaming the directory,
reformatting all csv's so everything was stored as strings in double
quotes, it still failed on an existing database (updated) but would work
fine on a fresh database.  Somehow it exhibits the same behaviour where
ir.model.data search returns an empty list.  So maybe some entry is left
over.  Deleting the module entry in GUI, and then restarting the server
and updating the modules it worked.

3. This behaviour is not limited to the hyphen problem.  I had an entry
called Travel, Meals and Entertainment in the chart, it was not enclosed
in quotes.  This brought about a quite correct error of no reference to
parent xxx.Meals and Entertainment.  However after correcting the csv's
it starts to exhibit the above error.

4. There is additional behaviour that is exhibited sometimes, if the
file is corrected without following the above steps.  And that is that
it will just not import anything at all, and start any configuration
actions.

I have experienced on latest 6.0.2 sources (as of yesterday) on Linux,
and have user reports confirmed on Windows as well.  The best way to see
this behaviour is to set a breakpoint at line 733 or 735 (or the
exception line) in the ORM within _get_id function and step over, while
using a bad csv file or directory.

I'm not concerned that it kicks up a fuss about bad csv files and stupid
developer symlinks and chucks an error, but that it is so difficult to
recover after correcting - and I think the bug is more related to
ir.model.data than csv import.  Maybe just throw an exception if a
hyphen is in the path.

While I highly do not recommend this, if you want files to test, good
files is latest rev of lp:~gdgellatly/openerp-au/l10n-nz-minimal-coa,
bad files is rev 3 of the same.  Just do it on something you don't mind
breaking (a fresh database is fine).

** Affects: openobject-server
     Importance: Undecided
         Status: New

-- 
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/787256

Title:
  importing a bad csv file in module, and subsequent correction causes
  issues

Status in OpenERP Server:
  New

Bug description:
  There are a few strands to this.  Some I can't confirm except to say
  they occur on my machine.  I'm not even sure what the bug is I'm
  reporting.

  1. If the relative path of a symlink includes a hyphen then I think
  the import doesn't work.  It chucks a no reference error in the
  client.  On checking, this is because there are no entries in
  ir.model.data when _get_id is called, the code excepts, silently
  passes and continues.  Often this means the error at the end is in no
  way related to the actual error, as it excepts all the way through,
  but doesn't raise immediately so the exception gets overwritten.  I
  think the csv importer deals with it fine, so when debugging you see
  the right lines in the right place.  I think the issue might be where
  ir.model.data gets populated.  I seem to remember that xml has an
  issue with hyphens from when installing the bzr-xmloutput plugin for
  bazaar where you need to rename the directory with an underscore.

  2. Upon doing a number of things, like renaming the directory,
  reformatting all csv's so everything was stored as strings in double
  quotes, it still failed on an existing database (updated) but would
  work fine on a fresh database.  Somehow it exhibits the same behaviour
  where ir.model.data search returns an empty list.  So maybe some entry
  is left over.  Deleting the module entry in GUI, and then restarting
  the server and updating the modules it worked.

  3. This behaviour is not limited to the hyphen problem.  I had an
  entry called Travel, Meals and Entertainment in the chart, it was not
  enclosed in quotes.  This brought about a quite correct error of no
  reference to parent xxx.Meals and Entertainment.  However after
  correcting the csv's it starts to exhibit the above error.

  4. There is additional behaviour that is exhibited sometimes, if the
  file is corrected without following the above steps.  And that is that
  it will just not import anything at all, and start any configuration
  actions.

  I have experienced on latest 6.0.2 sources (as of yesterday) on Linux,
  and have user reports confirmed on Windows as well.  The best way to
  see this behaviour is to set a breakpoint at line 733 or 735 (or the
  exception line) in the ORM within _get_id function and step over,
  while using a bad csv file or directory.

  I'm not concerned that it kicks up a fuss about bad csv files and
  stupid developer symlinks and chucks an error, but that it is so
  difficult to recover after correcting - and I think the bug is more
  related to ir.model.data than csv import.  Maybe just throw an
  exception if a hyphen is in the path.

  While I highly do not recommend this, if you want files to test, good
  files is latest rev of lp:~gdgellatly/openerp-au/l10n-nz-minimal-coa,
  bad files is rev 3 of the same.  Just do it on something you don't
  mind breaking (a fresh database is fine).