All right guys,

I spent a few hours digging into Dukai's error case with adding such a view:

<record id="product_product_tree_view_replace" model="ir.ui.view">
            <field name="name">product.product.tree.customization_replace</field>
            <field name="model">product.product</field>
            <field name="type">tree</field>
            <field name="inherit_id" ref="product.product_product_tree_view"/>
            <field eval="7" name="priority"/>
            <field name="arch" type="xml">
              <tree string="Products" position="replace">
                <tree colors="red:virtual_available&lt;0;blue:state in ['draft', 'end', 'obsolete'] or exportable == False" string="Products">
                    <field name="default_code"/>
                    <field name="name"/>
                    <field name="variants"/>
                    <field name="uom_id"/>
                    <field name="qty_available"/>
                    <field name="virtual_available"/>
                    <field invisible="'partner_id' not in context" name="price"/>
                    <field name="lst_price"/>
                <field name="shop_price"/>
                    <field groups="product.group_product_manager" name="standard_price"/>
                    <field groups="base.group_no_one" name="state"/>
                    <field groups="base.group_no_one" name="exportable"/>
                </tree>
                </tree>
            </field>
        </record>



Yes I saw the error and I was unable to find a clean fix.

Now, I tell you, Dukai this is a psycho use case (no offense ;-) )
Indeed, Why the hell would you like to inherit a view to actually replace entirely its fucking content?
IMHO this is plain wrong and never seen such a case.

What you should do instead is just REPLACE the original view by your new definition, that is, simply use the same record id and don't use inherit_id at all.

Of course, REPLACING an existing view is EVIL, just like not calling super when overriding a method. Now, I fully understand why you want to replace it, it's because you would like to cheat the tree attribute and the current OpenERP framework don't let you do that.

This is until why get my blueprint implemented and merged two (all right could be trunk this time if you are hypocritically scared): https://blueprints.launchpad.net/openobject-server/+spec/merge-attributes-view-extension-point

The good part of me spending those few hours now is that I now I know how I'll implement that blueprint in the close future.


NOW, LET'S ME SUM IT UP FOR THAT BRANCH:

Dukai found a psycho fail test case. BUT, he should never have done it this way and there is a better way to do it (use same record attribute no inherit_id) AND I NEVER SEEN SUCH A PSYCHO CASE IN THE ADDONS CODEBASE AT LEAST. Moreover, for the psycho's around, the fix will be dead simple.
So I vote for not blocking this merge under the pretext we found a psycho case breaking it.

I tested it for more than one week, several real customer profile/databases and no bug at all unless we try to blend the views in such irrational ways.


All right,

So I think this is enough testing, we had a fear with Dukai's case, but I affirm after deep investigation this was not justified.

So, please, I think we are quite a lot of experts now recommending the merge.
This is not for the fun of riding the bleeding edge, no, this is because doing nothing with XML libs that have been deprecated for ages would harm the Ubuntu OpenERP community (among others) in ways that are much worse for the OpenERP product image and hence community basis.

Best regards