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
When a sale is done on the website, a corresponding sale order is created in the
backend. By default the salesperson and sales team associated to the sale are as
defined on the website.
When we prepare values, we fallback on the partner sales team in a way that is
coherent with the way it falls back on the partner for the salesperson.
opw 1882640
Fix on sale_coupon (enterprise) https://github.com/odoo/enterprise/pull/2224 needs this change to be able to merge
SO lines when a program generates multiple discount lines on different taxes.
Closes#24971
task-1866977
task-1832967
task-1857843
Commit d25719cd use in website_sale the field sale_delay defined in stock and
so only available with the module bridge website_sale_stock only.
After this commit, website_sale without stock works again.
This commit closes#26855, closes#24671
Let's consider a product P with a sale_delay = 10
When creating a SO for P in the backend, the customer_lead is correctly
set to 10. But when creating a SO in the shop for P, the customer_lead
was not correctly set.
opw:1880577
With 60300fc, people can use promo code on website.
But the condition leads to a side effect, if a partner has a pricelist set for
him, he will never be able to see the dropdown list of pricelist since he will
enter the else condition with show_visible set to true.
Now, user is able to see selectable pricelists.
opw-1869371
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
In website_sale setting, there is a field 'Confirmation Email' that is not used,
and which purpose is to have a conveninent link to edit the mail templates.
Since it is an editable setting, this confuses the users.
It was in readonly before commit:
https://github.com/odoo/odoo/commit/65a7531c8b5c713969e49a5fab9d4672524c3ba8#diff-3f25fe0e27881e9c6655bbb6974c84abR59
which removed the readonly without any apparent reason.
We put it back into readonly mode.
opw 1860167
Purpose
=======
In the website_sale.product_variants template, for the "checked" attribute in the radio input,
it must be " checked' if variant_id_index == 0 else None " instead of "' checked' if
variant_id_index == 0 else '' ".
For this moment, it checked the last variant because we get " checked="checked" " for the
first and " checked="" " for the others.
Specification
=============
Use None instead of '' for the checked attribute if it shouldn't be checked.
When the carousel is activated, the following will load all variant ids
in the cache (cf. `_in_cache_without`):
```
<t t-set="variant_img" t-value="any(product.mapped('product_variant_ids.image_variant'))"/>
```
When accessing the `image` field at:
```
<div t-if="variant_img" class="..." itemprop="image" t-field="product.product_variant_id.image" t-options="..."/>
```
All variants in cache will have their image resized by the method
`_compute_images` on `product.product`. In case of a product with
hundreds of variants with images, this will take a major amount of time.
If we replace by `product[:1]`, the system uses another cache, and
doesn't fetch the image of all variants.
opw-1844783
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
Nothing prevents to click on the 'Pay Now' button, although the shipper
rating has failed. Moreover, the error is not displayed in the label of
the shipper.
Workaround: we force a click on the selected default shipper to trigger
the update. The good solution would probably be to have a completely
dynamic shipper rating integration, instead of some processing at first
rendering and then extra dynamic processing.
opw-1838765
Lucas Perais (lpe)