When ordering on the ecommerce,
if a payment transaction was found in the session,
this transaction was used as transaction for the current order.
Nevertheless, if the transction is no longer linked to
the current order, we should not use it.
This happened, for example, when the quotation
was deleted while the customer/user didn't close
its browser, and the transaction id was therefore
still in its session.
opw-650417
[FIX] Valuable checkout hooks for website_sale
[FIX] Values might need to be changed for different field mappings
[FIX] Make definition of form fields inheritable within a function
[FIX] Make shipping_info values available for inherited module manipulation
Close#8490
As eCommerce is not complete and could be improved easily and was
not working anyway until
9d0cb024fd
- Use EAN13 instead of internal product id if available
- Add tax to transaction data
- Add shipping costs if available to transaction data
Product pages ulrs can be indexed by searches engines.
The product category can be included in the url.
If the category has been deleted, accessing
this page should still work anyway
opw-648008
When placing an order in the ecommerce, it's
seems obvious that the partner is a customer.
Nevertheless, It wasn't flagged as such in
its partner from, preventing
to see him in the customers list
Fixes#2422Closes#2881
Not just when coming back from the payment provider to the
payment validation route `/shop/payment/validate`.
Otherwise, if you do not come back from the payment provider
page, that you quit just after having paid but just before
being redirected to Odoo, you do not receive the email.
The change within the `sale` module, while this issue concerns
`website_sale` only, has been accepted because this is a mechanism
that could be used by other modules.
opw-644348
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
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
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
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
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.
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 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.
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.