Merge lp:~akretion-team/openerp-product-attributes/polymorphic-relations into lp:~product-core-editors/openerp-product-attributes/7.0
Status: | Merged |
---|---|
Approved by: | Guewen Baconnier @ Camptocamp |
Approved revision: | 211 |
Merged at revision: | 205 |
Proposed branch: | lp:~akretion-team/openerp-product-attributes/polymorphic-relations |
Merge into: | lp:~product-core-editors/openerp-product-attributes/7.0 |
Diff against target: |
348 lines (+153/-41) 3 files modified
product_custom_attributes/product.py (+13/-11) product_custom_attributes/product_attribute.py (+111/-21) product_custom_attributes/product_attribute_view.xml (+29/-9) |
To merge this branch: | bzr merge lp:~akretion-team/openerp-product-attributes/polymorphic-relations |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pascualon (community) | Needs Fixing | ||
Benoit Guillot - http://www.akretion.com (community) | tested | Approve | |
Guewen Baconnier @ Camptocamp | code review, no test | Approve | |
Review via email: mp+150725@code.launchpad.net |
Description of the change
Hello,
This is the round 2 of my proposed generalization of product_
So it does what the commits says:
[IMP][product_
[IMP][product_
Notice that if that is accepted, I plan a very simple round 3 that will just consist in extracting a part of that module into a lower level custom_attributes mixin module that could be injected in any OpenERP object, not just products.
I also plan a little demo to show the power of this change. I know that it's not a trivial merge. However, I insist that the former behavior is largely preserved (if not totally) while accepting such change could make this module used in many more situations by much more people. Or said differently: it's makes it a little more complex but then more people will be maintaining it and IMHO this is totally worth the few additional lines of this merge.
Be the LGTM Gods with me!
Note: you may probably wonder why that new attribute_ option_ wizard wizard?
Well it's here to trick the OpenObject widget framework to make it easy to pick a few references to a custom OpenERP model (the relation_model_id of the attribute) while this model can change.
We could have left the user edit the value_ref field in the option_ids tree. But polymorphic m2o widget are a big PITA to edit in OpenERP (try to search for a specific model inside the selection to understand) and it would have been tricky to warranty the consistency: all option_ids lines should belong to the same model, the one selected in the relation_model_id field. All in all, from my experience, such a wizard is the less ugly way to offer that kind of user interface.
Hope this clarified the reason why.