[REGRESSION in 5.0.11] mandatory fields that should be inherited are now reported missing!

Bug #595758 reported by Raphaël Valyi - http://www.akretion.com on 2010-06-18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description


On 5.0.x stable, since server revision #2066 by Jay Voara, there is an important regression (meaning that 5.0.11 has it and previous versions are OK):

usually, if you create an object which inherits an other existing object and you specify that object id to inherit from, then the object validation should take into account the existence of the inherited fields by means of that specified id.

To be more concrete, here is what I do, I try to create a product.product (a variant) and I specify an existing product.template through the template_id field. So fields such as 'name' should be inherited from that specified product.template and that's how it was working before revision #2066.

However, after #2066, the server will complain that the field "name" is missing in that case!

If I create a product.product without specifying a tmpl_id, then that's true, the 'name' field is mandatory. But If, on the contrary I'm inheriting like here, I just want to inherit that field and I don't want every inheriting object to try to write the same parent 'name' field!

A way to reproduce the issue is to install the product_variant_multi module from the extra addons, then if you try to create a variant (in the product menu) you'll get that error, just like the attached screenshot. Of course you don't even need to install that module to detect the issue, you can detect it with a webservice or trying to load an XML record.

In the case of the product_varian_multi test, the GTK client logs are explicits:
DEBUG_RPC:rpc.request:('execute', 'ooor_test', 1, 'admin', ('product.template', 'name_get', [3], {'lang': u'en_US', 'tz': False}))
DEBUG_RPC:rpc.request:('execute', 'ooor_test', 1, 'admin', ('product.product', 'create', {'price_extra': False, 'product_tmpl_id': 3, 'default_code': 'var3', 'dimension_value_ids': [(6, 0, [])], 'active': 1, 'price_margin': 1.0}, {'lang': u'en_US', 'active_ids': [351], 'tz': False, 'active_id': 351}))
WARNING:rpc.exception:CODE warning -- Integrity Error

null value in column "name" violates not-null constraint
: Integrity Error

For information that regression has been detected with the OOOR RSpec unit test suite here: http://github.com/rvalyi/ooor/blob/master/spec/ooor_spec.rb
(just run rspec path_to/ooor_spec.rb to execute the test suite)

specially the following statement that now fails:

it "should skipped inherited default fields properly, for instance at product variant creation" do
  #note that we force [] here for the default_get_fields otherwise OpenERP will blows up while trying to write in the product template!
  create({:product_tmpl_id => 25, :code => 'OOOR variant'}, {}, []).should be_kind_of(ProductProduct)

Again, this has deep consequences, I think you better revert the commit if no fix is found because currently it looks like you tried to fix multi-level inheritance at the cost of breaking the single inheritance feature which is a bit nonsense...

Hope to see this reverted or fixed, thanks.

Related branches

Hi Raphaël Valyi,

I will check it very soon and will post more.

Thanks a lot for reporting.

Changed in openobject-server:
status: New → Confirmed
Anup(SerpentCS) (anup-serpent) wrote :

Hello Raphael,

   I have checked the issue, It was a breaking issue for single level inheritance only when there exists an id of the parent record. I have fixed it. Would you please check the attached patch and notify us.


Changed in openobject-server:
status: Confirmed → In Progress
assignee: nobody → Anup (Open ERP) (ach-openerp)
Anup(SerpentCS) (anup-serpent) wrote :

Hello Raphael,

   Here is a better solution for the problem. Please check it and notify us.

Thanks for reporting.

Anup(SerpentCS) (anup-serpent) wrote :

It has been fixed by Revision 2072 <email address hidden>

Changed in openobject-server:
status: In Progress → Fix Released


The patch fixes the bug.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments