At 96f038a product-related fields were removed due
to an important product.template/product.product
refactoring. As the field values were simply
dropped, they may not be nullified when upgrading an
existing database. Forcing them to False will take
care of it.
When no order is forced, it's more user-friendly if the products are ordered by alphabetical order.
This will mainly be applied:
* In the list view in the back-end
* In the eCommerce, for products with equal website_sequence
When uninstalling/updating a module, we may execute unlink method on product.template before product.product. In such cases, the product is already removed after removeing the template (_inherits) and the chained unlink of the product would fail (traceback when browsing).
This can give a performance boost on large databases
and should not be a concern in terms of access control
as the inheritance already grants access to the parent
records.
[FIX] product: user who don't use product variant can't edit the price of the product in product view. This behavior is not understandable. Add a function inverse to set the value (remove the variante price before change the list_price of the template)
product.product reuses most of the product.template views however some parts need to be excluded or replaced.
Instead of adding template only parts in base view and removing it for product, split the views in 'common' (product_template_form_view), 'template only' (product_template_only_form_view) and 'product only' (product_normal_form_view) where the first is inherited by the other two. The attribute mode='primary' on both second views allows to make sure that future inheritance of product_template_form_view and product_template_only_form_view will work with the full rendered product_template_form_view view.
This allows us to have valid buttons in crm for bill of material (filters based on active_id).
Also cleaning the mess with circular dependencies.
In new API, selection field value is checked (against the selection's possible
values) at both read and write. For pricelist.type this requires read access
to product.pricelist.type.
The lst_price field on product.template is a related to list_price. As we do not allow to set a value for related fields at creation (see orm.py , L4180), we display the list_price instead (float field).
On the product.product form, we display the lst_price (function field, readonly) as we don't want to allow changing the template price from the product. opw 609497
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Josse Colpaert
Fabien Meghazi
Christophe Simonis
Denis Ledoux
Olivier Dony
Commandant Custo
rsi-odoo
Fabien Pinckaers
Christophe Matthieu
Hardik Ansodariya
kevin wang
Frederic van der Essen
Thomas Groutars
Martin Trigaux
Richard Mathot
qdp-odoo
xmo-odoo
Xavier Morel
Atul Patel
Raphael Collet