* The compiled templates are cached per user, lang, inherit context values
* ir.ui.fields: attributes method return an dict, and record_to_html return only the content value of the field
* all rendered text use build_text and all attributes use build_attribute
* t-esc-options is removed and replace by format_value method
* AssetsBundle receive the list files and remains
When the user has several addresses, the call to the onchange method
`onchange_partner_id` will overwrite the actual invoice address chosen.
opw-675935
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
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.
Before this revision,
when a user tried to pay his cart with a first acquirer
e.g. Ogone
then came back to the shop (using the browser back button)
then chose another acquirer
e.g. Paypal
a new transaction is created, due to the change of acquirer
(following revision cb9d798)
and therefore, the transaction has a new reference compared
to the last payment transaction attempt (e.g. the ogone one)
but, the old reference is still referenced within
the `Pay now` form values, because the page wasn't re-rendered,
because the user pressed the browser back button, and this
doesn't refresh/re-render the page, and, therefore,
the old reference was still referenced within the `Pay Now`
form values.
Therefore, the wrong reference was sent to the acquirer
(e.g. paypal) and this prevented the payment validation
at the payment feedback, as the new reference was expected
in the feedback information, while we receive the older one.
This revision makes sure to always re-render the `Pay now`
form, so the transaction reference, as well as the other
possible changes in the values, are correctly set,
before sending the information to the acquirer.
- remove field complete_name
is the same as the ORM field display_name, compute the name_get
- website_publish_button is duplicated
- write outdated, according to TODO (field color already renamed)
- Instead of open_website_url, should use website_publish_button
- styles, style_in_product, attrib_encode: are no longer used in templates
- remove unnecessary rebrowse
This check was added at d3678bf5 either
- to prevent browsing as public user (wrong as always browsed with SUPERUSER_ID)
- to refresh fields of the record (I find your lack of faith in the cache
invalidation distrubing)
- remove get_pricelist method
equivalent to call request.website.get_current_pricelist
The pricelist in the context is only useful when computing the price of the
product.
Do not modifiy request context but only a local copy.
active_id is only used for the computation of the extra price from variants
Adaptations following rev. 1684ae4:
The website pricelist is now dynamic, according
to the pricelist chosen by the customer on the website.
It's no longer a static pricelist, it's no longer
the public user pricelist.
Therefore, when computing the variants prices,
the prices should no longer be converted
from the public user pricelist to the current (context)
pricelist, but from the product currency to the
current pricelist chosen by the customer on the website
In addition, when getting the unit price,
`/shop/get_unit_price`,
the website current pricelist should always be used,
it should never fall back on the partner pricelist,
as, it's the user who choose his pricelist from the website
now (if he has specific set on his partner
form, it's that one which is loaded by default, and which
is returned by the website.pricelist_id)
In addition, the displayed currency on the ecommerce
must always be the current website pricelist currency
Adaptations following rev. 3622c0d:
A product can have no company set (not required).
Therefore, when attempting to set the `from_currency`
to the product company currency, this could return
`None`, if no company was set on the product.
`product.currency_id` ensures to always return a currency
for the product. It's the company currency
if the product has a company set, otherwise it take it from
the main company (`base.main_company`).
In addition, when editing the product price from the website,
the price must be displayed within the product currency,
as, if changed by the user, it changes the product sales
price directly on the product form, without any currency
conversion applied or whatever.
opw-670898
opw-671100
If a customer had several delivery address,
and at checkout, choose another one than the default one,
his choice was applied, the delivery address remained the default
one.
This is a regression in Odoo 9.0 introduced in revision:
0414c9d.
The checkout shipping was applied only when it was a new
delivey address, due to the identation.
Part of the indentation issue was solved in 0f25a8c
opw-669787
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.
When configuring the payment acquirer with the confirmation
`at_pay_now`, meaning the sale order has to be
confirmed when clicking on the "Pay now" button, instead
of waiting for the payment confirmation,
the confirmation email wasn't not sent.
opw-665697
Before this revision, in the ecommerce,
a new payment transaction was created only
when the transaction reference was different than
the order number, meaning that the transaction id
in the user session no longer refers to the current order,
that the user created a new order which has nothing
to do with the transaction he has in his session
variable `sale_transaction_id`
This made sense when the transaction reference
strictly matched the order number, but,
since f89e8f9df2,
this is possible that a payment transaction reference
number no longer strictly matches its order number,
as the transaction reference can contain `-1`, `-2`
at the end of its reference, meaning there was
already another transaction existing with the sale
order number as reference. But the transaction
is still about this order.
Therefore, from this revision, the condition on
which a new transaction has to be created
should no longer be based on the transaction
reference, but to which `sale_order_id` the transaction belongs.
In addition, we add two more conditions for which a new transaction
should be created:
- The transaction has been cancelled or in error
- The acquirer has changed.
For the second case, this is to handle a corner case:
- The user selects one payment acquirer (Ogone), then click
on "Pay now", and is therefore redirected to the payment provider website (Ogone)
- Then, the user opens a new browser tab on the ecommerce, on his cart,
choose another payment provider (Paypal), then click "Pay now" and is
redirected to this second payment provider website (Paypal),
- Then, the user comes back on the first tab, on which he is on the first
provider website (ogone), and pays/validate the payment
- Then, we receive the payment feedback (either from the user/DPN, either from
the server to server call/IPN)
Before this revision, this use case would have lead to the feedback from the first
provider (`/payment/ogone/accept`) while the transaction is set with the second
payment provider (`Paypal`), therefore breaking the payment validation.
Creating a new transaction when the user changes of payment provider solves this issue.
He will nevertheless be able to pay twice, on each provider, but it was
already the case before.
opw-659294
We force to recompute the taxes on all lines when we change the fiscal position.
That was already done in backend, with the onchange.
But @api.contrains allow to do it on each write on fiscal_position_id field.
@api.Depends will not work because it is not a computed field.
On a list of product, the attribue list (can be activated via the
customize menu) only contains the attribute pertaining to current
filtered product list.
Also, all the values of a the attribute are showed, even if choosing a
value will result in an empty product list.
It could lead to usability issue in some situations.
e.g
1) the current showed products number 2 with an attribute color,
2) we select "Red" which isn't a value these 2 products are declined in,
3) the current show products is now empty, but we can't un-select the
"Red" color since "Color" is not an attribute of any of those 0
product.
This commit solves this issue by displaying the currently selected
attributes if no product is displayed.
opw-653594
When a partner is created, the fiscal position is set automatically if
possible. This is not correct, the fiscal position should only be set
automatically on a SO, based on the delivery address.
Here is a scenario explaining the reason:
- Create 2 fiscal positions, one in US and one in Canada. Both fiscal
positions apply automatically depending on the country.
- As an non-logged user, go in the web shop
- Buy a product
- At the checkout phase, the Billing Information are in US, but the
Shipping Information in Canada.
- The fiscal position which will apply will be US, while you expect it
to be Canada
The reason is that the fical position which applies is the one on the
parent partner (US in this case), since all children partners must have
the same accounting data.
With this fix, we simply remove the automatic setting of the fiscal
position on the partner.
opw-653072
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
Christophe Matthieu