This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
The new product configurator introduces the possibility to create
variants dynamically. One of the main goal is to be able to create
product templates with **many** attributes and values, but not generate
all variants automatically. Only the necessary variants are created
on-the-fly.
However, it turns out that **many** dynamic attributes and values still
fails. For example, create a product with 10 attributes, 10 values for
each. This allows 10^10 theoretical combinations; although the variants
are not created, the creation of the product template fails.
The reason is that the `variant_matrix` contains the list of all
combinations, which causes a `MemoryError`.
An easy modification to improve the process is to keep an iterator
instead of generating the list. This avoids the `MemoryError`, but it
remains necessary to go through all combinations three times, which
would take too much time.
Therefore, some refactoring is necessary in order to keep the same
logic, but avoid going through any huge list. Here are the improvements:
1. Skip the creation part if nothing will be created.
If any attribute is dynamic, no variant is created. Therefore, we can
perform the check upfront and skip the variant creation part if
possible.
2. Stop the creation loop as soon as possible.
There is an hardcoded limit of maximum 1000 variants to create. We
can perform this check along with the list creation instead of
checking at the end.
3. Determine if a product has valid attributes in a different way.
The existing logic is safe but expensive: we check that all attribute
values of a product are part of the possible combinations. This can
be simplified by checking if (1) all attribute values of a variant
are part of the accepted attribute values of the template and (2) a
variant uses all attributes of the template. The second check is
mandatory to delete existing variants when an attribute is added to
the template.
Thanks to these modifications, we at worst go through 1000 possible
attribute values combinations. It might still be possible to optimize
step 3 with a fancy SQL query which would retrieve all (in)valid
products at once. Hopefully this won't be necessary and the optimized
logic will be enough.
opw-1902392
closesodoo/odoo#28530
Targets commit d3530eb07e
Purpose
=======
[Follow up AL review]
Code cleanup and some improved models naming for the product configurator feature (see targeted commit).
Mostly changes the "product.attribute" related models.
Updated models:
- "product.product.attribute.value" to "product.template.attribute.value"
- "product.attribute.filter.line" to "product.template.attribute.exclusion"
- "product.attribute.line" to "product.template.attribute.line"
Updated fields:
- [sale_order_line in sale/sale.py] "product_custom_variant_values" to "product_custom_attribute_value_ids"
- [product_template_attribute_value in product/product_attribute.py] excluded_for is now a o2m instead of a m2m
- [product.attribute in sale/product_product.py] "create_variant" field is now a Selection with "no_variant" (old false), "always" (old true), "dynamic" (new value)
- [product in product/product.py] "product_attribute_value_ids" to "product_template_attribute_value_ids"
Purpose
=======
Product attributes can be configured to create variants "on demand".
This means that product.templates having these attributes will only create product.product variant
when that combination is actually selected in a sale order/in the web shop.
Product attribute values are also improved to handle extra prices and exclusions
in all three modes ("never", "on demand", "always")
Specification
=============
Create variants on demand
- add a new mode to generate variants as they are added to the order/cart
(needed for big # of combinations managed in the inventory and/or produced in mrp with specific boms)
- replace the boolean by a selection radio
tooltip for this new field:
Always:
Variants are generated straight away when
the attribute values are combined in the product configuration.
Only when the product is added to a sales order:
Variants are generated once the combination is selected in the sales order.
This is advised when variants are customized on demand and manufactured as such in Odoo.
Never:
Advised when variants are not needed in Odoo.
The selected values just show up in the description of sales order lines.
- ability to define attribute extra prices & exclude combinations in all variant modes
- if at least one attribute of the product in set to "on demand" mode, generate all the variants "on demand"
Task #1871557
Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
Specification
=============
PHASE I
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
Commit dc1681b1 did change the name of the inventory creation from
direct qty update, but test still tries to compare the product.name
closesodoo/odoo#25948
In 11.0 7e724f96c5 is_product_variant has been introduced back (it was
removed in 10.0 b747b05fa). But related of _inherits are computed on the
related model so is_product_variant would always be false.
Without fix, added test fails with:
AssertionError:
Items in the first set but not the second: True, Items in the second
set but not the first: False, Product variants are variants
fixes#26961
related to opw-1814973
closes#27163
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
In 5c2380e9f an issue when modifying variants values was solved when an
attribute on the product variant had "create_variant" unset.
This commit forward-port what was lost of it in 11.0, that part was
probably lost because the code was previously changed when adapting to
python3.
Without the change, the added test failed creating a new variant keeping
the existing one. With this change, 'nocreate' value are ignored when
computing new variants to create.
opw-1815226
closes#23332
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
PURPOSE
=======
It's confusing as it's not used. We had a customer with two exact same rules; he complained to the
support today because Odoo decided to use the other rule. (he was confused because he thought
priorities were based on sequences as there is a sequence field that allow drag & drop)
Order is based on "applied_on, min_quantity desc, categ_id desc", not on sequences. (since v9
and it's better that way; but we forgot to remove the sequence field)
SPECIFICATION
=============
Remove field
A new API is introduced for price computing using pricelists. It is simplier
to use in most use cases, which is computing the product price in a given
pricelist. Old methods return dictionnaries and tuples, which are rarely
used in the code.
product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Old price_get method is now replaced by price_compute and ready for migration.
Explicit parameters for unit of measure and currency have been added to ease
code understanding.
Including
- unit tests for test/inventory.yml
- unit tests for test/move.yml
- unit tests for test/shipment.yml
- integration of test_reuspply.py
- integration of test_owner_available into test_product.py
New tests are temporarily deactivated. Indeed they rely on onchange methods
that will change during migration. Tests will be reactivated after migration
and updated.
Remaining products :
- product_product_0 becomes service_order_01
- product_product_1b becomes service_cost_01
- product_product_43 becomes product_order_01
- product_product_47 becomes product_delivery_01
- prodcut_product becomes product_delivery_02
- Replace product_product_56 by service_delivery
- Replace product_product_59 by consu_delivery_01
- Replace product_product_58 by consu_delivery_02
- Replace product_product_57 by consu_delivery_03
Removed products :
- product_product_53, product_product_57, product_product_55, product_product_54, product_product_52,
product_product_51, product_product_50, product_product_48, product_product_46, product_product_32,
product_product_33, product_product_28, product_product_38, product_product_39, product_product_40,
product_product_41, product_product_34, product_product_29, product_product_30, product_product_44,
product_product_31, product_product_35, product_product_36, product_product_37, product_product_42,
product_product_45, product_product_49, product_product_26, product_product_14, product_product_15,
product_product_18, product_product_19, product_product_21, product_product_23
Removed corresponding binaries.
Removed all Bill of Materials demo data, that were ridiculous and replace them by 2 bom: A complete
computer, and a kit computer. Rewritten the tests accordingly.
Fixed tests :
- sale_mrp/test/cancellation_propagated.yml : The yaml ref function return a id, not a dictionnary
- sale_stock/tests/test_sale_stock.py : The service product invoiced on the delivered quantity was
in fact not invoiced on delivery on the test. As we are in sale_stock, Without timesheet, we
manually set the delivered qty for the product serv_del. If we don't do this, the invoice will
never be fully invoiced.
- The pricelist rules choice is not based on the sequence anymore (Seems to be a bug, reported to
online). By the way, I changed the product to avoid the overlap.
- sale_mrp/test/sale_mrp.yml: The yaml ref function return a id, not a dictionnary
- mrp : Rewritten the tests to be coherent with the new bom data
Pricelist computations need to consider 2 different Units
of Measure:
- The default product UoM (product.uom_id), used as reference
for the various quantities and amounts specified in each
pricelist rules.
- The `context UoM` is the UoM in which the result is requested,
that is the list price UoM.
For example the 'price_min_margin' amount is meant for the unit
price of 1 x default UoM. When the context UoM is not the default
product UoM, it can be any UoM of the same UoM Category, and the
various quantities and amounts specified on the rule need to
be adapted accordingly:
- min_quantity (expressed in terms of the default UoM)
- price_surcharge (specified for 1 x default UoM)
- price_min_margin (specified for 1 x default UoM)
- price_max_margin (specified for 1 x default UoM)
The UoM corrections were not done consistently and resulted in
wrong prices when computing the price using a non-default UoM.
The cases were a conversion was needed or not were not properly
identified within the _price_rule_get_multi().
After this commit, the various code branches in _price_rule_get_multi
always ensures that:
- price requested for: `qty` of `qty_uom_id`
- `qty_in_product_uom` is the requested `qty` converted to default UoM
- current (intermediary) price: `price` for `price_uom_id`
Therefore `price` and `price_uom_id` are always in sync, and `price_uom_id`
can always be compared with `qty_uom_id' in order to know whether
a conversion is still needed.
This patch also corrects and extends the regression tests
introduced at revision 79ebe10.
Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.
An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.
Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.
This problem was initially solved using an extra rounding.
However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)
At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.
Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.
Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.
Two extra tests have been added to cover Example 1 and Example 2.
--
Related to #2072, #1125, #1126, #2672Closes#2495, #2498
The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor).
This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727).
Added test checking the correctness of pricelist computation based on unit of measures.
Sébastien Theys