xml template was using color name, because color index was empty.
It works in English, but once translated (in french e.g.) we have background-color:noir
Fix#12251
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
When processing a payment transaction, double-check the
match between the amount of the transaction and the
amount of the SO, to be sure that we won't be validating
a SO that has been modified since the payment.
Such cases have to be double-checked manually.
Also add a bit of extra logging to make auditing ecommerce
transactions easier.
This revision is related to 9752aedb4e
It looks like in some cases, the user cannot read the
partner associated to his own cart.
This is the case when shopping without being signed in.
opw-673187
When attempting to pay a cart in the ecommerce,
if the customer went on the payment acquirer site
(meaning, the `payment.transaction` is created
in the database), then come back to the checkout form
using the browser back button, and changed his customer
details (address, email, phone,...),
these changes in the details were not applied
in the `payment.transaction` record that was being
re-used.
e.g.
Checkout > Confirm > Choose Paypal, Pay Now
> History back to the checkout and apply changes
in the address > Confirm > Pay Now.
When validating a payment transaction,
if the cart (order) cannot be confirmed or
the email cannot be sent for any reason
(instance, the email template is broken),
the transaction must continue, so the payment
transaction can be set to `done` or `pending`.
In other words, not sending the confirmation
email or not confirming the sale order must
not be blocking to mark the payment
transaction as done.
opw-672486
This controller was very slow as not providing a pricelist computed the price of
all products of all pricelists.
Instead only fetch the prices for the useful products.
Suggested alternative descriptions spill out of the boxes if the
description is too long.
PS: same fix as in saas-6 with f7110b46bef2d84cd2ce864f5bdd747457099e1e.
This fix doesn't have to be forwrad ported.
opw:667343
Each time the quantity of a product is changed, the price must
be updated according to the pricelist of the user.
When the price given by the pricelist is less then the unit price
of the product, the reduction of the price must be displayed.
A not stored computed field is added in model "sale.order.line"
to compute the discounted price because when the module
product_visible_discount is installed the price unit of a SO line
is the full price of the product and the discount related to the pricelist
is written in percent in the field discount(function "product_id_change"
in addons/product_visible_discount/product_visible_discount.py).
opw:660178
The variants on a product in the ecommerce can appear:
- naturally, not a list, colored square for color, ...
- in a list of radio button.
To have the second kind, we need to enable the "List View of Variants"
customize option.
One part of the code was not the same which cause an issue when saving
the image of the variant, it was saved on the product.template instead.
This commit add an "update_product_image" function which is now called
in both scenario.
first half of:
opw-654279
forward port note: in 9.0 website/image -> web/image
When clicking on button "add_to_cart" for a product with several options,
the user must be redirected to the product page. In this way, the user can
choose the options, he wants to buy with the product before adding the product
in the cart.
opw:653356
Previously, if there was a sale_order_id but it was wrong,
like when the sale order was deleted for example, the function
didn't return a sale order, even with force_create=True.
It used to pass the first 'if' as sale_order_id had a value, so
no new sale order was created. However, as sometimes the id was
referring to a non-existant sale_order, a sale_order.exists() test
was used later, resulting in the function sometimes returning None,
even with force_create = True.
Proposed solution is to test the existence of the browse record with
the given id earlier, instead of testing the existence of the id itself.