View Inheritance issues

ocset · **Joined:** Tue Mar 09, 2010 4:08 pm **Posts:** 117

Hi

I get inheritance and I love the way it works in the OpenERP server. The client side has me confused because I cannot add to a field without completely replacing it.

Here is the issue. I want to add user restrictions to the standard_price(Cost Price) field in product_view.xml file. I have added the following code to the a new module:

Code:

<record id="product_product_tree_view" model="ir.ui.view">
       <field name="name">product.product.tree.inherit</field>
        <field name="model">product.product</field>
        <field name="inherit_id" ref="product.product_product_tree_view"/>
        <field name="arch" type="xml">
          <field name="standard_price" position="replace">
          <field name="standard_price" groups="base.group_parts_admin"/>
       </field>
........

but have found that it is interfering with the following piece of code in the stock module

Code:

<field name="standard_price" position="replace">
  <label string="Cost Price:" align="1.0"/>
  <group col="2" colspan="1">
    <field name="standard_price" attrs="{'readonly':[('cost_method','=','average')]}" nolabel="1"/>
    <button name="%(action_view_change_standard_price)d" string="Update"
                            type="action" icon="gtk-execute" attrs="{'invisible' [('cost_method','&lt;&gt;','average')]}"/>
  </group>
</field>

Although I am replacing the "standard_price" field completely, the label remains behind and I get "Cost Price:" repeated twice on the screen

Is there a way to just add the groups tag to the field as is possible with standard inheritance. Surely this is a design issue because I won't know who is overwriting the field definition before me.

Thanks
O

gdaddy · **Posted:** Wed Jun 29, 2011 8:22 pm

That stock overwrite is awful, it should be changed. I can see why it has been done aesthetically, but it does create all sorts of problems.

If you only did it in the base view then you would lose the other parts. It is a pretty rare case that someone overwrites a perfectly good field gives it a manual label and then sets it to nolabel, and if you wanted to get in to it then maybe priorities will help you, but personally save yourself the hassle and just update your view with nolabel="1" in the field definition.