When using multi-company, the base currency of a product is the currency of the
main company, not a contextual company.
closes#29905closes#29946closes#30046
In commit f8dad1bb4b, we tried to fix the currency
conversion of products by always using the currency of the product as the base.
This is still correct.
However, the conversion method also needs to know the company (to find the
correct currency rate), and it was assumed the company was also always set on
the product. This is of course not correct when using multi-company.
In this commit we fix that issue by falling back if no company is set on the
product. The order of the fallback is: product website company, given website
company, given pricelist company, current user company.
closes#29905closes#29946closes#30046
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
This revision is related to
12df3c6a98
The above revision serve its purpose as well,
but by avoiding to store the result in a variable,
and using the records cache instead,
we gain some memory, which is noticeable
when there are hundred of thousands products.
The sudo() is important, as it must be the
same environment then the above call to read
to use the same cache.
Otherwise the values won't be in the cache
of self (without sudo),
and it will go get it and prefetch other fields
in the database.
Oversight in revision
a91ffcf1a7
Multiple products can have the same template.
Passing multiple times the same template id
to the search domain to get the sellers
works, but better avoid the repetition
for the performances.
By prefetching only the fields required for the `name_get`
`product.product` & `product.template`
have a huge number of fields,
and prefetching them just to compute
the name is overkill.
Especially, as the browse was done using
sudo, the prefetch was a bit useless as
it was stored in the sudo user cache,
which was most-likely not used afterwards
by the callee of name_get
For a database with 50.000 products,
this reduce the processing time
by 15 (from 60 seconds to 4 seconds measured)
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
Following commit b43151c11c
The order of the pricelist items on the interface was made deterministic, but
there was still a problem with the actual computation because the SQL was
created manually and used a different order than the _order of the model.
Moreover, it is better to use id DESC instead of ASC to make sure the
automatically created default rule matching everything is actually applied last.
PR: #28476
Targets commit d3530eb07e
Purpose
=======
- When a product variant is archived by the user, it should not be selectable in
the product configurator for both webshop and sale order
- Fixed a typo in the name_get method of ProductTemplateAttributeValue
closesodoo/odoo#27385
Targets commit d3530eb07e
Purpose
=======
- Exclusions for optional/accessory products do not work for attributes configured as "never create variants".
These attributes are now added to the reference_product context so that they can be taken into account when
evaluating exclusions.
Many users are confused when using pricelists on the PoS :
When they tick the box "Show discount" on the pricelist, it has no impact when the pricelist is applied on the PoS.
They often report a ticket thinking it's a bug.
It can be useful to show the discount on the PoS when applying a pricelist, when users benefit from a preferred price,
the vendor often wants to show it to the customer.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
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"
Purpose
=======
Product attrivutes can now have custom values.
These values are specified by the user during the SO creation.
They are also available on the webshop frontend.
Specification
=============
add a new mode to generate variants as they are added to the order/cart
- ability to define attribute extra prices & exclude combinations
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
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose: improve understanding of partner and product models as well as their
daily use. This is done by improving tooltips and labels of some fields
according to business logic.
This commit is related to task ID 1880696 and closes PR #27133 .
Thanks to @xmo-odoo for its in-depth review.
Commit: 70e1efd41e
Explicitly added an _order on product.attribute.value.
However the order that should be used first is the one from product.attribute.
It would not make sense to display ipod (white, 8go) and ipod (8go, black).
opw 1883904
On product packaging model, the uom is related to the product uom but
but editable. This can lead to some error in the database. This commit
set it as readonly to avoid any mistake.
Co-authored-by: Denis Roussel <denis.roussel@acsone.eu>
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
In event_sale it is possible to have one product representing several tickets. But before this commit, on the sale order and invoice the client only saw the name of the product and didn't know which event/ticket they subscribed to.
The goal of this commit is to overwrite that behavior whenever a sale order or invoice line is related to an event ticket, to show the ticket name and event name instead of the product name.
Technically, the following changes have been done:
----------------------------------------
* various: add a method to compute a default name for a SaleOrderLine, based on its product
I added the method because the code to compute the name was duplicated in several places. This will make it more consistent.
Moreover this gives the option for modules to override the method to define a custom name as necessary.
----------------------------------------
* event_sale: compute a consistent description for a SaleOrderLine based on an EventTicket
The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language.
The default description will be computed as follow:
1. The ticket name should be the first line of the product description on the SO.
2. The event name should be the second line of the product description on the SO.
To compute the ticket multi-line description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name.
We also ignore them because the work-flow of creating a new event does not lead to filling them correctly, as the product is created through the event interface.
----------------------------------------
* event_sale: improve sale order line and event registration views
It was possible to select a ticket related to a product before an event was selected.
This is typically the case for tickets defined in an event_type but not in an event.
The ticket field is now hidden until both the product and the event have been selected.
This way we are sure the selected ticket will belong to an event and not an event_type.
We reset the ticket on event change because we don't want the user to be able to select a ticket belonging to the wrong event.
We also improve here the comments of the related on-change methods.
----------------------------------------
* website_event_sale: update views to show ticket name and event name
The standard behavior was to show the product name in several places instead of the sale order line description.
However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
----------------------------------------
* website_event_sale: add ticket on confirmation page
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
----------------------------------------
Task: 1837987
PR: 25819
In purchase we add a stat button that counts the number of purchase
orders linked to the product.
In this commit we change this count to count the quantity of products
linked to a purchase order.
We basically do the same thing with the stat button of sale (sale
orders) and mrp (manufacturing orders).
Sébastien Theys