Update to current trunk breaks menus

[Kyle Waid]

When updating to the current trunk even from last friday, the home menus are broken. The accounting menu is missing all of the items, and the home menu displays incorrect items.

While --update=all it deletes several ir records and throws a few errors.

Steps to reproduce.

Have a week old installation, download latest sources then update. Menus broken.

Something to do with base.ir.model.data, and views deletes a ton of records. Also points to res.groups could not delete.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello, I tend to confirm this bug: we encountered it when trying to upgrade our production customers.
As I had no time to investigate, I reverted to rev #3224 to avoid the issue.
If this is not fixed, it's a very bad issue for all the people who invested in helping you to build and test the v6.

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Hello Kyle,

Would you please provide me your database which you are using for testing with the latest code.

As I do not have any old database, So I can check your issue at my end with the latest code.

Thanks.

[Kyle Waid (midwest)]

Hi, I believe you could download the rc2 code from your website and test with that. You should coordinate with Raphael Valyi as he is better suited to describe the issue. I cant provide a copy of our database to you without approval but i will ask tomorrow.

[Kyle Waid (midwest)]

To be more specific, When updating the server It deletes many entries and fails at a few of them. Here is an output server log.

[2011-01-12 13:52:12,962][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:12,972][midwestdev] ERROR:addons.base.ir.model.data:Could not delete id: 3 of model res.groups
There should be some relation that points to this resource
You should manually fix this and restart with --update=module
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/addons/base/ir/ir_model.py", line 745, in _process_end
    self.pool.get(model).unlink(cr, uid, [res_id])
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/addons/base/res/res_user.py", line 582, in unlink
    ', '.join(user_names))
except_osv: ('warning', 'Warning !')
[2011-01-12 13:52:12,973][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:12,986][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,012][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,032][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>act_window
[2011-01-12 13:52:13,044][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,059][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,071][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,087][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>act_window
[2011-01-12 13:52:13,103][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,120][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,133][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,146][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,157][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,168][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,189][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,199][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>act_window
[2011-01-12 13:52:13,214][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,225][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,238][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,251][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,267][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,280][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>act_window
[2011-01-12 13:52:13,291][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>act_window
[2011-01-12 13:52:13,308][midwestdev] INFO:addons.base.ir.model.data:Deleting <email address hidden>
[2011-01-12 13:52:13,318][mi...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello, I confirm the issue is still here today with server rev #3260

Azazahmed, I'm pretty sure you can reproduce the bug by trying to migrate an RC2 demo database to your last server code (then do --update=all for this to happen).
I'm afraid, neither Kyle or me can provide you the database as it's production confidential data.

Can you reproduce the bug?

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

I'm afraid I'm not able to reproduce it. Here's what I did:

$ createdb test_install
$ bzr up -qr tag:6.0.0-rc2 addons
$ bzr up -qr tag:6.0.0-rc2 server
$ ./server/bin/openerp-server.py -d test_install -i crm,account
(...installs demo db with crm and account, on server RC2...)
^C
$ bzr up -q addons
$ bzr up -q server
$ bzr revno --tree server
3260
$ ./openerp-server.py -d test_install -u all
(...updates all, a few yaml warnings, no missing menus..)

If you can reproduce it with this testcase, then there must be something else going on...

Note that the error message about not being able to delete stuff can be ignored, and will not cause any issue.
Views and menus are only deleted at the end of an update if they have disappeared from the updated modules.
If the database is reasonably recent, no mass deletion of these should happen at all, unless a module is somehow updated without its dependent modules.. which is not supposed to happen (e.g. updating base should update all modules)

And in any case, running another update=all should re-create the missing menus/items, as part of the normal loading of the modules.

Can you perhaps provide the full log of the update=all run, in case something else can be noticed there?

[Jay Vora (Serpent Consulting Services) (jayvora)]

Raphael,

I am having the same experience as Azazahmed, Unable to face this.
I have my DBs made on 4th and 5th jan, and they work pretty normal.

We are ready to investigate if we have a test DB where you have faced it. I understand you cannnot pass on a DB,but can you try by making a demo db and try again? It would help really.

I just did a little test and came to a point that your config file might have missed --addons-path parameter.
Can you please check if it is so?

I am a bit confused to mark it confirmed or invalid. Your inputs will help us.
1. ./openerp-server.py --addons-path=../../addons and installed account module.
2. ./openerp-server.py --update=all -d trunk13

Step 2 Gave me:

LONG traceback.

[2011-01-13 22:24:57,818][trunk13] INFO:init:updating modules list
[2011-01-13 22:24:58,732][trunk13] WARNING:init:module analytic: module not found
[2011-01-13 22:24:58,732][trunk13] WARNING:init:module analytic: module not found
[2011-01-13 22:24:58,737][trunk13] WARNING:init:module decimal_precision: module not found
[2011-01-13 22:24:58,737][trunk13] WARNING:init:module decimal_precision: module not found
[2011-01-13 22:24:58,741][trunk13] WARNING:init:module web_livechat: module not found
[2011-01-13 22:24:58,742][trunk13] WARNING:init:module web_livechat: module not found
[2011-01-13 22:24:58,743][trunk13] WARNING:init:module board: module not found
[2011-01-13 22:24:58,744][trunk13] WARNING:init:module board: module not found
[2011-01-13 22:24:58,754][trunk13] WARNING:init:module process: module not found
[2011-01-13 22:24:58,754][trunk13] WARNING:init:module process: module not found
[2011-01-13 22:24:58,762][trunk13] WARNING:init:module base_setup: module not found
[2011-01-13 22:24:58,762][trunk13] WARNING:init:module base_setup: module not found
[2011-01-13 22:24:58,764][trunk13] WARNING:init:module product: module not found
[2011-01-13 22:24:58,764][trunk13] WARNING:init:module product: module not found
[2011-01-13 22:24:58,770][trunk13] WARNING:init:module account: module not found
[2011-01-13 22:24:58,770][trunk13] WARNING:init:module account: module not found
[2011-01-13 22:24:58,788][trunk13] WARNING:init:module base_iban: module not found
[2011-01-13 22:24:58,788][trunk13] WARNING:init:module base_iban: module not found
[2011-01-13 22:24:58,798][trunk13] WARNING:init:module account_voucher: module not found
[2011-01-13 22:24:58,799][trunk13] WARNING:init:module account_voucher: module not found
[2011-01-13 22:24:58,803][trunk13] WARNING:init:module l10n_be: module not found
[2011-01-13 22:24:58,804][trunk13] WARNING:init:module l10n_be: module not found
[2011-01-13 22:24:58,805][trunk13] WARNING:init:module account_chart: module not found
[2011-01-13 22:24:58,805][trunk13] WARNING:init:module account_chart: module not found
[2011-01-13 22:24:58,815][trunk13] WARNING:init:module account_accountant: module not found
[2011-01-13 22:24:58,815][trunk13] WARNING:init:module account_accountant: module not found
[2011-01-13 22:24:58,817][trunk13] WARNING:init:module base_vat: module not found
[2011-01-13 22:24:58,817][trunk13] WARNING:init:module base_vat: module not found
[2011-01-13 22:24:58,825][trunk13] WARNING:init:module...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Jay, Olivier, Azazahmed and Kyle,

my logs look pretty much as the one passed here by Kyle: it only looks that
the server is setting menu entries (view and menus) as to delete and at the
end it deletes them while it was not supposed to happen. I'm not sure why
subsequent --update=all doesn't work, then we just get errors about missing
records.

I'v been able to make a patch that avoid breaking the menus this way,
however I'm pretty sure that's only a workaround and not something valid for
the long run. Using the following patch I'm finally able to migrate my db
without breaking it all:

=== modified file 'bin/addons/base/ir/ir_model.py'
--- bin/addons/base/ir/ir_model.py 2011-01-10 12:33:02 +0000
+++ bin/addons/base/ir/ir_model.py 2011-01-13 16:40:09 +0000
@@ -725,7 +725,9 @@
    def _process_end(self, cr, uid, modules):
        if not modules:
            return True
        modules = list(modules)
        module_in = ",".join(["%s"] * len(modules))
        cr.execute('select id,name,model,res_id,module from ir_model_data
where module IN (' + module_in + ') and noupdate=%s', modules + [False])
         wkf_todo = []
         for (id, name, model, res_id,module) in cr.fetchall():
             if (module,name) not in self.loads:
- self.unlink_mark[(model,res_id)] = id
+ if module != 'base':
+ self.unlink_mark[(model,res_id)] = id
                 if model=='workflow.activity':
                     cr.execute('select res_type,res_id from wkf_instance
where id IN (select inst_id from wkf_workitem where act_id=%s)', (res_id,))
                     wkf_todo.extend(cr.fetchall())

So basically, I'm here avoiding to mark base records with noupdate=False as
to remove.
May be it can put you on the track: do you think it's normal that we select
those records in that query? If not how can you explain that? Do you think
those records should have a noupdate=True rather than False? Is that
possible that some poisoned recent revision put False instead of True in
those ir.model.data?

Thanks.

On Thu, Jan 13, 2011 at 3:01 PM, Jay Vora (OpenERP) <email address hidden> wrote:

> Raphael,
>
> I am having the same experience as Azazahmed, Unable to face this.
> I have my DBs made on 4th and 5th jan, and they work pretty normal.
>
> We are ready to investigate if we have a test DB where you have faced
> it. I understand you cannnot pass on a DB,but can you try by making a
> demo db and try again? It would help really.
>
> I just did a little test and came to a point that your config file might
> have missed --addons-path parameter.
> Can you please check if it is so?
>
> I am a bit confused to mark it confirmed or invalid. Your inputs will help
> us.
> 1. ./openerp-server.py --addons-path=../../addons and installed account
> module.
> 2. ./openerp-server.py --update=all -d trunk13
>
> Step 2 Gave me:
>
> LONG traceback.
>
> [2011-01-13 22:24:57,818][trunk13] INFO:init:updating modules list
> [2011-01-13 22:24:58,732][trunk13] WARNING:init:module analytic: module not
> found
> [2011-01-13 22:24:58,732][trunk13] WARNING:init:module analytic: module not
> found
> [2011-01-13 22:24:58,737][trunk13] WARNING:init:module d...

[Jay Vora (Serpent Consulting Services) (jayvora)]

Thanks for being quick Raphael,

The solves the issue, but doesn't hide,speaking honestly.

We need to think why the self.loads{} has no entry for module and its xml_id.

I have been going through some reverse engineering how to generate this error and I see the root leading me to:
self._unlink_mark --->self.loads -->def _update_dummy inside ir_model.py.

Try except block can play a vital but villion 's role.
I will post more as I investigate more.
Thanks.

[Jay Vora (Serpent Consulting Services) (jayvora)]

*The patch solves the issue, but doesn't hide,speaking honestly.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Jay,

thank you for your time.
Well, I'm still investigating it. What I can tell you so far is that my self.loads isn't empty, Now it's so hug that I cannot check for the involved entries in my log, I'll need to do investigate differently.

Also, I think we need to double check if that wouldn't be some side effect of this magentoerpconnect related bug:
https://bugs.launchpad.net/magentoerpconnect/+bug/673614
Any idea?

Cause both Kyle and me are trying on database where magentoerpconnect is installed (though it's not the same project at all).
Also, we are trying to update yet an other of our project where it's likely we made updates before at similar revisions that would allow to know better if might be magentoerpconnect related or not.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Thanks for the feedback Raphael.

I've tried the same way out as you mentioned on bug 673614 like x.y.view_id. And, I got the same error of many DOTs.

OpenERP has a standard for any XMLID as a name without DOT and if a DOT is specified, it is to be understood as DOT is separated by MODULE and XMLID which interprets as the XMLID has been referred from MODULE module.
e.g. base.group_extended

Specifying more than one DOTs just confuses the server and makes it impossible to track for the server to find the root module of that xmlid. Thus, it has been asserted by the assert tag and server throws an assertion failure that you have specified more than one DOTs.

Possibly,this is what unmatched to self.loads {(MODULE_NAME,XML_ID):(MODEL_NAME,ID in DATABASE)}.

Additionally note that, having such an XMLID breaks the loading, but doesn't call deletion of menus at all.

Ultimately, the current issue is still a mystery.

Thanks.

[Kyle Waid (midwest)]

I know this is very long, but I was asked show the entire log. This log is from the sources to date as of when I posted this message.

[Kyle Waid (midwest)]

[2011-01-13 14:05:30,106][?] INFO:server:OpenERP version - 6.0.0-rc2
[2011-01-13 14:05:30,106][?] INFO:server:addons_path - /usr/local/lib/python2.6/dist-packages/openerp-server/addons
[2011-01-13 14:05:30,107][?] INFO:server:database hostname - 192.168.1.34
[2011-01-13 14:05:30,107][?] INFO:server:database port - 5432
[2011-01-13 14:05:30,107][?] INFO:server:database user - openerp
[2011-01-13 14:05:30,107][?] INFO:server:initialising distributed objects services
[2011-01-13 14:05:30,375][?] INFO:web-services:starting HTTP service at 0.0.0.0 port 8069
[2011-01-13 14:05:30,376][?] INFO:web-services:starting HTTPS service at 0.0.0.0 port 8071
[2011-01-13 14:05:30,376][?] INFO:web-services:Registered XML-RPC over HTTP
[2011-01-13 14:05:30,378][?] INFO:web-services:starting NET-RPC service at 0.0.0.0 port 8070
[2011-01-13 14:05:30,378][?] INFO:server:Starting 3 services
[2011-01-13 14:05:30,381][?] INFO:server:OpenERP server is running, waiting for connections...
[2011-01-13 14:05:40,655][dev] INFO:init:module base: loading objects
[2011-01-13 14:05:40,658][dev] INFO:init:module base: registering objects
[2011-01-13 14:05:41,122][dev] INFO:init:module base: creating or updating database tables
[2011-01-13 14:05:45,832][dev] WARNING:osv.browse_record.ir.ui.view:No field_values found for ids [974] in browse_record(ir.ui.view, 974)
[2011-01-13 14:05:45,833][dev] WARNING:base.ir.module.module:Unknown error while browsing ir.ui.view[974]
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/addons/base/module/module.py", line 126, in _get_views
    aa = v.inherit_id and '* INHERIT ' or ''
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/osv/orm.py", line 285, in __getattr__
    raise AttributeError(e)
AttributeError: 'Field inherit_id not found in browse_record(ir.ui.view, 974)'
[2011-01-13 14:05:45,847][dev] INFO:init:module base: loading base_data.xml
[2011-01-13 14:05:46,898][dev] INFO:init:module base: loading security/base_security.xml
[2011-01-13 14:05:47,050][dev] INFO:init:module base: loading base_menu.xml
[2011-01-13 14:05:47,519][dev] INFO:init:module base: loading res/res_security.xml
[2011-01-13 14:05:47,623][dev] INFO:init:module base: loading res/res_config.xml
[2011-01-13 14:05:47,700][dev] INFO:init:module base: loading data/res.country.state.csv
[2011-01-13 14:05:48,666][dev] WARNING:osv.browse_record.ir.ui.view:No field_values found for ids [974] in browse_record(ir.ui.view, 974)
[2011-01-13 14:05:48,666][dev] WARNING:base.ir.module.module:Unknown error while browsing ir.ui.view[974]
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/addons/base/module/module.py", line 126, in _get_views
    aa = v.inherit_id and '* INHERIT ' or ''
  File "/usr/local/lib/python2.6/dist-packages/openerp-server/osv/orm.py", line 285, in __getattr__
    raise AttributeError(e)
AttributeError: 'Field inherit_id not found in browse_record(ir.ui.view, 974)'
[2011-01-13 14:05:48,673][dev] INFO:init:module base: loading base_update.xml
[2011-01-13 14:05:48,937][dev] INFO:init:module base: loading ir/wizard/wizard_menu_view.xml
[2011-01-13 14:05:48,990][dev...

[Kyle Waid (midwest)]

I do not have any special modules, and the only modules I have installed from the extra-addons branch are chart for us general profile, product categories for magento, openlabs images, base_external_referentials, base_sale_multichannels, and openerp6-module

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

On my side,

I can tell you that I just installed magentoerpconnect and dependent modules
and I'm able to update as I want this new database. So that's still a
mystery. Still investigating...

On Thu, Jan 13, 2011 at 6:13 PM, Kyle Waid - http://www.midwestsupplies.com
<email address hidden> wrote:

> I do not have any special modules, and the only modules I have installed
> from the extra-addons branch are chart for us general profile, product
> categories for magento, openlabs images, base_external_referentials,
> base_sale_multichannels, and openerp6-module
>
> --
> You received this bug notification because you are subscribed to
> OpenObject Server.
> https://bugs.launchpad.net/bugs/701644
>
> Title:
> Update to current trunk breaks menus
>
> Status in OpenObject Server:
> Incomplete
>
> Bug description:
> When updating to the current trunk even from last friday, the home
> menus are broken. The accounting menu is missing all of the items, and
> the home menu displays incorrect items.
>
> While --update=all it deletes several ir records and throws a few
> errors.
>
> Steps to reproduce.
>
> Have a week old installation, download latest sources then update.
> Menus broken.
>
> Something to do with base.ir.model.data, and views deletes a ton of
> records. Also points to res.groups could not delete.
>
>
>

[Kyle Waid (midwest)]

If by that you mean you made a new database and installed magentoconnect and dependent modules I was also able to do this easily. It only gives the problem when updating an older database, not even that old. I know 1 other

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

My findings so far:

1) We managed to migrate an other database with no magentoerpocnnect that is likely to have been updated at the same server revisions. So this and the fact that nobody else can reproduce the bug tend to make it likely it's somewhat related to magentoerpconnect and dependent modules.

2) Some findings: the content of the ir_model_data records looks OK for my database that won't upgrade. I compared it with a fresh database which will migrate and it's the same for the ir_model_data of the "base" module.

3) I managed to print the content of self.loads where module == 'base'. Here is it with my database that won't update:

**** ('base', 'menu_base_config')
**** ('base', 'menu_procurement_management_supplier')
**** ('base', 'menu_main_pm')
**** ('base', 'menu_procurement_management_supplier_name')
**** ('base', 'menu_reporting')
**** ('base', 'menu_mrp_root')
**** ('base', 'menu_product')
**** ('base', 'menu_base_partner')
**** ('base', 'menu_administration')
**** ('base', 'menu_action_currency_form')
**** ('base', 'menu_sales')
**** ('base', 'menu_purchase_root')
**** ('base', 'menu_project_report')
**** ('base', 'menu_sale_config_sales')

And of course, all the menu component then are not found in self.loads, the list of ir_model_data records from base not found in self.loads then starts as:

not in loads: :(module,name) (u'base', u'maintenance_contract_add_wizard')
not in loads: :(module,name) (u'base', u'action_maintenance_contract_add_wizard')
not in loads: :(module,name) (u'base', u'menu_maintenance_contract_add')
not in loads: :(module,name) (u'base', u'odony_twitter_widget')
not in loads: :(module,name) (u'base', u'matrixise_twitter_widget')
not in loads: :(module,name) (u'base', u'rvalyi_twitter_widget')
not in loads: :(module,name) (u'base', u'maintenance')
not in loads: :(module,name) (u'base', u'menu_maintenance_contract')
not in loads: :(module,name) (u'base', u'albertnan_twitter_widget')
not in loads: :(module,name) (u'base', u'nhomar_twitter_widget')
not in loads: :(module,name) (u'base', u'access_maintenance_group_user')
not in loads: :(module,name) (u'base', u'access_maintenance_contract_module')
not in loads: :(module,name) (u'base', u'maintenance_contract_tree_view')
not in loads: :(module,name) (u'base', u'maintenance_contract_form_view')
not in loads: :(module,name) (u'base', u'maintenance_contract_search_view')
...

So Jay, I believe you were right, it must be some kind of exception happening when updating the base module that fail silently and prevent from putting those records in self.loads as it should be.

It's pretty late here now, but the next step is definitely to hunt for those exception by looging more inside those try blocks. This all is a long process cause my database that won't migrate has 2 years of Magento data imported + BR localization, so it takes between 5 and 10 minutes to migrate every time (which isn't that bad).

The fight continues...

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

@Kyle: thanks for posting the full log, it's useful, and already tells us a few things about what is not the problem: e.g addons-path, double update of base module, etc.

@Raphael: I can't think of any obvious reason why base_external_referentials could cause an issue, unless it creates badly named ir.model.data entries with 'base' as the module? Then perhaps it could interact with the update process. In any case, creating entries in ir.model.data outside of a module should always be done with noupdate=False, otherwise all these records will be dropped the next time the referenced module is upgraded (referenced module = module whose name is used in these additional ir.model.data entries)

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Guys,

Thanks for your posts.

Does any of your module override read() or update() of ir_model_data?

Possibly either of the following 2 things are causing problems:
1. Exception in read or update() of ir_model_data
2. If XML files are a problem,wrong XMLIDs specified(more than one DOTs) OR the problem of noupdate flag changed anyhow.

Thanks.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello guys,

I just re-tested and I tend to think even more it's a magentoerpconnect related bug: indeed: I had a fresh Magento database built with recent code, with no Magento related data, update was working, but as soon as I started importing data from Magento (eg generating ir_model_data records), updating the database was not working anymore with just the same menu bug (and so far, we had the case only with Magentoerconnect installations)

In order to confirm, I even tried to manually remove all the Magento related ir_model_data records using SQL on a copy of my production database to see if it would update but had the same bug still, I have no idea why.

Still I think I have enough clues to move the bug to the magentoerpconnect project and investigate from here. Thank you for your time. Will update the bug when I find solutions.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Thanks for the care taken Raphael.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

How to reproduce:

create a new database with magentoerpconnect module and dependent modules.
Create one new Magento referential in Magento-Connection>Core Settings>Magento Instances

try to restart the server with --update=all and KABOOM! your menus are gone...

So it seems it's not even related to what is inside our ir_model data as they aren't any new synchro ir_model_data at this stage.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

OK, I cannot believe I've not seen this before: even simpler:

new database with only base_external_referentials installed.
Then --update at restart will generate the bug!!

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

IMHO it's actually a server bug (a regression), in order to make it simpler I open a new bug and submitted it to the OpenERP team so they can look at it before the 6.0 release:
Detailed report of the bug here:
https://bugs.launchpad.net/openobject-server/+bug/704051

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

Note: the upstream bug 704051 at openobject-server is fixed, so I believe this bug could be closed as well, if you can confirm that the issue is fixed now.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello,

I confirm rev #3288 fixes the bug, many thanks to Olivier and OpenERP SA for that.