c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <704051@xxxxxxxxxxxxxxxxxx>]

Raphael, thanks for investigating in details this issue and providing a reproducible testcase.
It makes it easier to fix the issue! :-)

Basically, inheriting from ir.model.data causes the osv instance for 'ir.model.data' in the pool to be replaced, discarding the current list of known "XML ids", stored in ir.model.data.loads. 
Recently we changed the module data cleanup to be done globally at the end of the module install/update process, to avoid other issues, and thus it became important for this 'loads' cache of known XML ids to survive replacement of the osv instance in the pool.

The fix places a reference to this cache in an attribute of the pool object, to have it survive properly. It was pushed in 
server trunk with revision revision-id: odo@xxxxxxxxxxx-20110117184453-kxvbuzmuge6u1mh4

Note that the amount of module data being discarded by this bug depends
on the number of modules that were processed before the
base_external_referentials modules, which should be quite low, as it
only depends on base, and is processed before any module with deeper
dependencies. Also note that after updating to the latest revision and
starting another --update=all, any missing module data will be properly
restored, as long as discarded data only included actual module data,
and no data that 'pretended' to be part of a module.

Thanks for the bug report!

** Changed in: openobject-server
       Status: In Progress => Fix Released

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

Title:
  [6.0] regression: inheriting ir_model_data causes data from 'base'
  module to be discarded

Status in OpenObject Server:
  Fix Released

Bug description:
  Hello,

  sorry to shout that one loudly, but I know that v6 "stable" is about
  to be release, so I want to make sure you take a look to it:

  A change introduced recently in the server (after rev #3224 I think),
  will now destroy important database records in the update process if
  you have any object inheriting the ir.model.data object.

  Simple code like this one will trigger the bug, it's attached as a
  "kaboom" module so you can test:

  class ir_model_data(osv.osv):
      _inherit = "ir.model.data"

  ir_model_data()

  After loading such code, if you restart the server with option --update=all --database=your_base,
  your database will be broken, for instance all your menu will be broken at the next login. You can also see that in the console with logs such as:
  [2011-01-17 15:24:43,983][magento] INFO:addons.base.ir.model.data:Deleting 23@ir.actions.act_window
  [2011-01-17 15:24:43,991][magento] INFO:addons.base.ir.model.data:Deleting 13@ir.model.access
  [2011-01-17 15:24:43,997][magento] INFO:addons.base.ir.model.data:Deleting 21@xxxxxxxxxx
  [2011-01-17 15:24:44,004][magento] INFO:addons.base.ir.model.data:Deleting 5@ir.actions.wizard
  [2011-01-17 15:24:44,009][magento] INFO:addons.base.ir.model.data:Deleting 43@ir.model.access
  [2011-01-17 15:24:44,015][magento] INFO:addons.base.ir.model.data:Deleting 127@xxxxxxxxxx
  [2011-01-17 15:24:44,022][magento] INFO:addons.base.ir.model.data:Deleting 11@xxxxxxxxxx
  [2011-01-17 15:24:44,028][magento] INFO:addons.base.ir.model.data:Deleting 2@res.groups
  ...

  
  An important consequence of that bug is that the magentoerpconnect certified module is now broken:
  https://bugs.launchpad.net/magentoerpconnect/+bug/701644
  We really need to override or_model_data in the base_external_referentials module, if you don't fix what triggers this behavior in the server, it would be pretty hard to make base_external_referentials and dependent connectors work again without patch...