If the transaction already exists, the amount total of the transaction must
be updated.
The case occured when:
[1] you put a product A in the cart
[2] click on "Process Checkout" and click "Confirm"
[3] select Adyen or Paypal as payment method
[4] click on "Pay Now"
[5] return in the cart instead of paying your order
[6] add a product B in the cart
[7] click on "Process Checkout" and click "Confirm"
[8] select Adyen or Paypal as payment method
[9] click on "Pay Now"
Now check the transaction payment linked to the order in backend, the total amount of the order is equal
to price A + price B and the total amount of the transaction payment is equal to price A.
This commit solves this problem.
opw:634119
Partial backport of commit 093e39bd.
When a flow is stopped by a login redirection, some data (e.g: a product
comment being posted) could be lost. This commit in this case convert
POST request data to GET data (so it is possible to add a GET controller
which after login will terminate the action).
closes#7100
opw-642350
The delivery must be updated when the cart is updated.
The method "_check_carrier_quotation" called by "_cart_update" deletes sale order line related to delivery.
Then each line passed to "_cart_update" must be checked with "exists" to be sure that the record is not
missing.
Related to the task : 12239
opw:641913
When filling the form (for invoice or delivery details), once a field has been
filled, it's no longer possible to remove the value of this field.
e.g. set a company, not possible to remove it when modifies the address
This is due to the `get(key)` call that is considered as False with empty
strings. Instead, check the existance of the key.
Still not accepting mandatory in the form (not checked in this method).
Fixes#7017
When a sale order has in state != draft, we raise a error message since commit
f6c65a3d9e.
But if we don't reset the sale order id from the session, the user cannot
continue to navigate on website because the user will have the error each time.
If the product to quick add in the cart has several variants, the button cart
redirects the user to the page of this product. If "attribute_value_ids" is not
in the DOM when clicking on the button cart, the product is immediately added in
the cart.
Closes#6714
opw:639897
When the user is not logged, there is no branding for the options.
This is why, the product_id of the option must be written in the
template "optional product".
opw:633093
Prior to this, even if your suggested or optional products were variants,
only the name of the template was shown.
Fixed GitHub issue 2746 and opw 614776
Each time a product is added in the cart, the qty of this product must be checked to
adjust the price if there is a rule (with min qty) in the partner's pricelist.
opw:630049
1) Activate pricelist + multi currency - Main currency is EUR
2) Create a pricelist in USD (named "test"), no specific rule is applied.
3) Go to website < shop < select a product < buy it.
4) On the page /shop/cart go to customize and make sure "coupon code" is ticked
5) Enter "test" in the coupon code field
--> The prices are changed according to the exchange rate of the currency of the pricelist.
This is not correct: the coupon should only affect the amount according to the discount,
not convert the amount in the currency of the pricelist. In the specific example, the price
displayed should not be affected.
opw: 630670
-Website.tours must be loaded after the translation data:
"website.ready" before the tour ensure that the translations are loaded.
-Translations for qweb templates not applied:
Translate all text nodes in qweb templates when translation data
are loaded.
-Add some translations in website tours.
opw:619786
While having a product list with 20+ products,
If more than two attributes were set in the shop filter,
going to the next page kept only the first filter.
opw-629188
In ecommerce products list view, if the product name was
shorter than the product price, than,
the product price overlapped the product description
Besides, this display: inline-block; has no useful utility
(at least not known), and it should be set in a CSS property
anyway
Previously, if you registered enough images to push the ipad one on page two, the test would fail to find it. Now it chooses the image with index 4, whatever it is.
This rev. is related to 67443b5b17
onchange_template_id returns the attachment_ids as a id list,
not as a *2many command list
The conversion from id list to command list has to be done manually.
At the moment, attachment_ids is the only 2many fields of email.template
On one hand, when a product attribute is shared by several
products, some may use different subsets of its possible values.
On the other hand, when less than 2 values are enabled for
a given attribute on a product, no choice is displayed for
that attribute on the shop page, as there is none to be made.
The way those "visible attributes" were computed in
get_attribute_values() was wrong: when counting the
number of values it used the whole range of possible
values for this attribute (cross-product), not just
those enabled for that product.
This lead to inconsistencies vs the website_sale.variants
template, and products using a single value out of a larger
range of values were constantly marked as "Not available"
in the shop.
The email_from for the order confirmation email in the ecommerce
was forced to the company email,
preventing any customisation concerning the from email address
in the sale order mail template.
When a model is regarded as public readable, no group should be set on the ACL,
to allow ANYONE to read the model, not just the users within the public group.
On ecommerce checkout, the language of the partner wasn't set according to the language in which he is visiting the website.
Therefore, its partner was set with the default language (English in most cases), and any emails sent to him were not translated in his own language (in the email templates, such as the quotation email he received on order confirmation)
When adding informational attribute, with only one possible value, it used to be skipped.
Instead keep it and add it on every variant.
To avoid dropping and recreating product (and lose eventual customisations), the attributes with only one possible value are set on every product.
This makes sure that in following test, these are not considered in variants_inactive variable.
Fixes#3204
The line being deleted in this revision looks to have been useful when it was introduced in this commit:
36fc910
As the sale order was updated right away through the update_pricelist method
But since this rev. 22f4c31, the sale order is updated later, and reset the sale_order_code_pricelist_id value in the session right after setting it prevent to apply the pricelist of the promotional code...
* `disabled` on the country select tag instead of `readonly`
* `create a new address` selected when the user set an invalid shipping
address and must correct it. Else the user was correcting the shipping
address but the option "ship to the same address" was selected.
The goal is to fill the page with at least 20 products and to fill all grid lines
Thus, the page should be filled with products until there are 20 products and all lines of the grid are full.
The customer can change the country and tax
number in the billing information during
checkout, and the taxes should be properly
updated according to the re-detected fiscal
position.
The fiscal position detection also depends
on the `vat_subjected` flag, which we now assume
to be implicit as soon as the customer filled
in a valid Tax Identification Number.
The old behaviour was not better, because when we print the invoice, the order was ugly:
Name
Street
Company name
Country
Now we will have:
Name
Company name
Street
Country
This patch is not retro-compatible:
Old partners will see the address in company name and vice-versa.
Need to update view and switch street field and street2 field
Orders are normally confirmed when the payment transaction
is processed, but there is no transaction for free orders.
This caused them to stay in draft until manually cancelled.
Add line id to while calling _cart_update() from sale_get_order()
The missing line_id parametre was making the _cart_find_product_line() call to fail as it was linked to an option while searching for lines without options (making the method recreate new lines).
Fixes#2573
Due to additional security rules, the transactions made as public user will have a new partner_id. The transaction needs to be retrieved as admin to be set in the context.
The operations in payment_get_status are made as superuser but the session_id is checked in the assert above to avoid url manipulation.