Purpose
=======
Since we now have the product_configurator in its own module, we can add a bridge module for the website_sale
to override the necessary controller routes in a cleaner way.
This commit just adds the bridge module and move files and code around, there should not be any functional change.
On /shop, we access the image field to generate the image widget, but we don't
actually need the image content, we just need its url. When `bin_size` is added
we don't compute all the resize for nothing.
opw-1923999
task-1922055
PR: #30274
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = account, purchase, website_sale_comparison, website_sale_wishlist
Raw Image & Mixin
=================
Previously, the main image from a product was stored resized. This caused
inconsistencies with the size of the images on ecommerce: the main image was
resized, but the extra images were not.
Now, we always store all raw images, thanks to the new mixin. This way, product
images that were created before the installation of ecommerce will be ready to
be used in ecommerce without any other change.
We also store the resized versions instead of computing them on the fly: this
will take more disk space, but significantly increase the speed of the
pages when displaying images, as well as reduce server CPU load.
Images on variants
==================
Previously, it was only possible to set the extra product images on a template,
and not on a variant.
Now, we allow extra images also on the variants, this gives more flexibility to
the user.
Both extra images on template and variant have been given a sequence field to be
able to sort them easily.
On /shop we always display the image of the template for performance reasons.
On /product we never display the image of the template, unless the variant has
no image, then the template image is the fallback.
Carousel
========
The carousel view has been cleaned and improved:
- remove the duplicate XML that was created with the product configurator fix
- use a single loop from a single source to get all the images, instead of
merging the different sources in the view with complex conditions
- improve the HTML structure, reduce the CSS with appropriate classes
Preview Image
=============
Both in website and backend: make better use of `preview_image` to display
a small image whenever possible, to reduce download size for the end user.
task-34045
PR: #30656
Co-authored-by: Parth Gajjar <pga@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
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>
Before this commit, self.env.ref would always find the generic view loaded from
the assets.
Disabling a customize_show view on a website would not hide completely the
feature as the self.env.ref would retrieve the active generic one and not the
inactive specific one.
Step to reproduce (on one of the module):
- Install website_sale_wishlist
- Disable "Wishlist" on the Customize menu of /shop
- Go to a product page, the wishlist hearth icon is still there
opw-1914576
Closes#29347
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
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
Add quantity key to context instead of overwrite the entire context
If another context key was present, it would be lost
Introduced at 166a9d26e3closesodoo/odoo#30519
There was multiple issues with `website_sequence` field, mostly coming from
commits during the last few years (eg 43c544f8a8) that tried to change the
`website_sequence` order to be the same as `sequence` but changing only part of
the code.
Other commits tried to restore that again by changing only some parts.
This commit does:
1. Originally, the `website_sequence` was supposed to be the opposite of
`sequence` field, the greater the first.
This commit ensure this is not the case anymore and it is used as the
regular `sequence` field.
2. `website_sequence` demo data was set between 4 and 1000, no need to use so
big differences. Plus, having a website_sequence set to 4 means the next
product would already have negative value.
3. Add `website_sequence` field in tree view in place of `sequence` for website
product view, and in debug mode on form view.
task-1960777
closesodoo/odoo#32593
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose of the task is when extra fee is activated on the payment acquirer,
the customer is no warned about extra cost when choosing the payment acquirer.
so display the extra fees on payment acquirer when doing the payment.
Related Task ID : 1845815
Closes : #31730
This commit extend commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7
When you have a cart on multiple session and confirm the card in one of them,
you could still access your cart from other session (note that you could not do
anything with it as it would be reset when adding product or changing qty).
Closes#28210
Before this commit:
If an user has multiple session on a database (eg: he is connected both on his
smartphone and his laptop on the ecommerce), and there is a cart in these
session, confirming the cart on one of the session will make other sessions
unable to use the checkout anymore.
This is because other sessions will still contains the Sale Order that is now
'sent' and updating the cart will raise an error:
`It is forbidden to modify a sales order which is not in draft status.`
Now:
If the SO to be updated is not in `draft` anymore, we create a new one.
Step to reproduce:
- Login on ecommerce from device A
- Add product in cart, the SO will be added on session
- Login on ecommerce from device B
- Pay the cart (it will retrieve the SO from device A)
- At that point, the cart is paid and the SO is removed from session on
device B but other devices won't be able to use the checkout anymore
as they still have the SO in session which is in `sent` state.
Thus, any action on cart will raise the error
Note:
1. We can't implement that behavior in `sale_get_order()` as it is supposed to
return SO in `sent` state after checkout.
2. We can't implement that behavior in `_cart_update()` as it is inherited in
some module. Thus, implementing that behavior in `cart_update()` would change
`self = order` but inherited methods would still have initial `self`.
3. Implementing the behavior in the controller it is already done (differently)
in `cart_update_json()`.
Fixes#27508, closes#27794
When an unlogger user places an order, a new partner is created on the fly when
the unlogged user is asked to place his delivery address.
The values he enters on the form are processed before being used.
In particular the team_id is taken from the order (typically website_sale team).
We add to the new values the salesperson id.
This value is then used in onchange_partner_id to update the order's user_id.
opw 1889510
closesodoo/odoo#28030
In v11, when we add the extra step in website checkout and
then click 'proceed to checkout', user will be directed to address
(even when there is default address detected), and then extra step,
and in the end confirmation.
But in v12, when extra step is enabled, user will be sent
directly to confirmation after clicking 'proceed to checkout'.
They can click 'extra info' to fill out the information,
but I imagine user would easily ignore that option.
It seems the express checkout implementation ignored extra_info route.
closesodoo/odoo#28122
The /shop route can take a `category` argument (a model converter).
`/shop/category/<model("product.public.category"[..]):category>`
But if that `category` argument is passed through URL query string
(?category=9), it will raise an error when doing
`category.can_access_from_current_website()`
as it is an integer since it did not went through the model converter
Note: Among probably others, that type of route is used when changing product
order on shop
Closes#27490, closes#27724
Since those two modules do not have a bridge, there was no support for changing the freeshipping line
when changing the delivery carrier
Now it has, at the price of ugly code
OPW 1871526
closesodoo/odoo#26935
Targets commit d3530eb07e
Purpose
=======
[Follow up JCR testing]
Various bug fixes including:
- optional products dont show when they have variants configured on them
- when no variant is created, you cant choose the product one first time in the ecommerce
- when in debug, attribute and attribute value menu is double
- fix design of default picture in cart summary / product comparison
- fix missing href tag on product comparison "add to cart" buttons
- products with the "Can be sold" box unchecked should not appear in the product configurator
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
Aurélien Warnon