Revision 15f27b2 introduced a dynamic form submission to
avoid some payment transaction problems.
It so happens that form submission in jquery necessitates
said form to actually be in the dom (at least for Firefox
and some version of MSIE); this revision ensures that the
form is updated in the dom by the rpc call then properly
submitted.
Since aae5647988,
the payment transaction ID is set in the session.
Unlike ecommerce carts, this is possible to open multiple
quotations at the same time
(one browser tab on SO001, another one on SO002),
and therefore to pay multiple quotes at the same time.
This revision makes sure to get from the session the transaction
of the right quote.
That way, the message "Your payment has been received, thank you for your trust.",
is not displayed when opening a new quote when another one was paid
just before.
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.
The condition self.uom_id != self.product_id.uom_id could actually
never be met, since a few lines before you could read
self.uom_id = product.product_tmpl_id.uom_id. From now on, simply
check if the uom_id on the cached record is different from the one
on the product and check the price using the pricelist (_compute_price
does not take pricelists into account) with the wonderfully explicit
with_context call.
Has been changed at d8e5cdec in the source but wasn't in the translations.
Replace also is .po files combined with a tx push to be able to add the new one.
Closes#10461
If we take content with $().text(), to insert it in another node we have to
used $().text(value) also. If like before this commit, we would use $().html()
the content would be unescaped one time too much.
note: equivalent of 8.0's 37ed5ce and 7ad626f commits
If we take content with $().text(), to insert it in another node we have to
used $().text(value) also. If like before this commit, we would use $().html()
the content would be unescaped one time too much.
When printing the online quote, using the "Print" button
in the online proposal in the front-end, the user
used to print the report is the SUPERUSER.
If `doc` or `o` is not set within the QWeb values,
the headers printed are the ones from the user company,
instead of the record company.
As this was the case in the `website_quote` report,
the company headers printed were not the sale order company
headers, but the SUPERUSER company headers.
opw-666306
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
This revision is related to 7be2403cf5
The payment acquirers must be fetched if the quote
needs a payment.
Besides, as explained in the above revision, the state
`manual` no longer exists sales orders, and therefore
this must no longer be used to determine if a quote
needs a payment or not.
opw-660575
Damien Bouvy