The function field selected_seller_id is removed and must be replaced
by a direct call to method `_select_seller`. This is more conventional
than the previous 'browse with context' way of doing.
We introduce a new field on supplierinfo: product_id. Thanks to this
field, the vendor information which will be used in a purchase order can
be specific to the product variant.
As the standard price on the product template changed towards the product variant,
we should also change the product price history to be by variant.
Also the inventory value calculated in the Stock Valuation report should be by variant.
The function field `volume` and `weight` on product.template were not
recomputed correctly.
The function field `standard_price` should not be stored as it's based
on a property field. Add a search function on it.
The function "name_search" defined on "product.template" made a search on
"product.product" name to give the "product.template" which matched with the
search. The number of results given by the name_search on "product.product" is
generally limited to 8. The problem was when for example there were 8 variants ("product.product")
with a name begining by "AA" for the same "product.template" T1 and another "product.product"
with a name begining by "AB" linked to T2. In this situation, if a name_search was made on "product.template" with a name="A",
the result got was just the the name of T1 linked to the 8 variants instead of the name of the
two templates (T1 and T2) due to the limitation.
opw:647066
Among a lot of views tweakings and cleaning, some changes are listed here.
product
- add currency_id, taken from the company
stock
- procurement request and inveotry adjustement wizards now correctly work
on product and templates with 1 or more variants. With one product the product
field is readonly, with a template and/or a product with variants the
product field is limited to the existing varians.
- valuation and cost method fields on the templates now come from property
fields defined on the template, or from property fields defined on the
product category. It allows to define those fields directly from the
category.Among a lot of views tweakings and cleaning, some changes are listed here.
membership
- details not visible in the default product view. However there is a specific view
to use in (membership / configuration / create member product)
Now using a method for the selection. This method is overriden in
various addons to add specific selection entries instead of
completely hardcoding the values. Indeed this breaks inheritance.
Some views have been updated to try to make the various attributes
more inheritable-friendly.
Main changes summarized
product
- [REM] weight_net field. Weight net is removed from the product model.
Indeed a product should be modeled without its possible packaging data.
Moreover in the codebase the weight_net field is not really used.
- unused import
- removed _common.py file holding wrappers for tools (rouding and
ceiling), used only once in the codebase
purchase
- unused imports
purchase_requisition
- dead code
- purchase_requisition: from boolean to selection, because V > M
stock
- [REM] qty_available2, logic, loc_rack, loc_row, loc_case fields. location_id
and warehouse_id moved from the product to the template to ease the
configuration.
- [ADD] description_picking field
stock_account
- [REM] date_account field on stock.inventory
misc wording (sale_margin, ...), notably Cost Price renamed to Cost.
- Add an option in the General Settings : Use product variant.
- If this option is disabled : don't show any reference to variants
- When going on the product template view, and clinking on the stat button under the tab Variants,
the form view should display only the information related to the variant
- Fields moves from product_template to product_product : weight, volume, cost price,
- DO NOT display these fields on the product_template if there are more than 1 variants.
- In product variant view, set some fields readonly and add a link to edit it from Template.
Using the new API takes better advantage of the cache than calling `read()`.
In the list of products, `name_get()` now generates 2 queries instead of 144!
If you filter the list of products with category, we don't display all the attributes,
but only the list of attributes impacted by the current sub-select of products.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
When the product is a consumable, avoid to use real-time valuation, by adapting
the onchange in the views and making the valuation field invisible when the
product is a consumable / service.
Before this rev.,
if you had two child categories with the same name, e.g.:
- Chocolates / Orange
- Fruits / Orange
In the product list, searching for category "Fruits / Orange"
also returned the products from category "Chocolates / Orange",
because it fetched all products which had "Orange" in the category.
This rev. corrects this (in the above example, it returns
only products from category "Fruits / Orange".
The code is particularly complex. A proper solution would be
to store the complete name field (but this cannot be done in
stable releases, such as 8.0).
Besides, it handles the fact a product category child can have
' / ' directly in its name (it's not only the category tree separator).
e.g., you could have a category name called 'Fruits / Orange' directly
not only in the complete name.
opw-628793
This rev. is related to 489a96c257
It wasn't possible anymore to perform an import of
a product.template field in a model
(e.g. mrp.bom), while it should be the case.
In the context of an import,
the operator of the name_search is '='.
Therefore, in this super call, the operator was '='
and the name was '' (empty).
In such a case, ('name', '=', '') is added
to the search domain by the base name_search method
(in models.py),
leading to the domain
[('id', 'in', template_ids), ('name', '=', '')]
which will lead to no results.
Forcing 'ilike' as domain is correct, as the actual
name_search, with the correct operator,
has already been performed in the lines above, the
point of this second name_search is to get
the right order along with the right name_get.
opw-632089
Raphael Collet