Old s2s prototype code has been removed. It is not used anywhere and not
supported. Moreover ogone s2s implementation use its own set of methods.
In a near future a neat implementation of s2s for paypal will be added.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
Introduces two new options:
- confirm_so: to confirm the sale order on acquirer confirmation
- generate_and_pay_invoice: confirm_so + generation of invoice and
payment registration
The third parameter expects a list of field, not some random string.
This made the constraints for the fields tagged with required_if_provider to be
never checked.
Closes#12458
When no `partner_id` was passed to `render()` and the acquirer
had a fees computation method, (e.g. Paypal), it would crash.
Could happen when coming through the /website_payment/pay
controller, for instance.
Otherwise recomputation may fail with "record does not exist or has been
deleted" when creating records with a value directly set for e.g.
'image_mediun' on a new product.
The issue comes from the storage of the images. When creating a product, the
creation of an attachment for storing the field `image_medium` triggers the
recomputation of that field before its dependency `image` is set. As `image`
is initially null, `image_medium` is recomputed as null, and this deletes the
attachment just created before the latter has completed its creation! As a
consequence, some code at the end of `create` for the attachment crashes
because the record has been deleted.
The following models have been fixed: `fleet.vehicle.model.brand`,
`hr.employee`, `im_livechat.channel`, `mail.channel`, `payment.acquirer`,
`pos.category`, `product.template`, `product.public.category`, `res.partner`.
opw 666330
Closes#11516
- add or fix decorators on methods
- fix most compute methods (wrong dependencies)
- revert changes in `eval_context` of `ir.actions`
- various code simplifications and improvements
- migrate methods that were not
- ir_qweb: modify `QWebContext` to take an environment instead of `cr`, `uid`, `context`
- ir_qweb: convert `AssetsBundle` to use new API `env`
- ir_ui_view: use decorator `multi` on method `read_combined`
- ir_ui_view: ensure that method `render` is never called with an xml_id
- ir_ui_view: factor out part of the `ormcache` key of method `_read_template`
The installation of a new acquirer was a bit complicated : from settings,
check the acquirer, then apply (install the module) then list view of
acquirer and finally edit it in form view.
This needed to be simplified. The payment acquirers are pre-filled
in payment. From the kanban view an `Install` button installs and
redirects to the form field.
Environment field on payment.acquirer model now has a shiny stat button on its
form view. It allows to toggle between production and testing mode.
All payment acquirers are by default in testing environment now, to avoid issues.
If the help message is translatable,
there is no reason why the thanks message
coudln't be as well.
This is a following of the revision
f37a40c4c0
opw-670228
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
The computed fees can depend on the country.
There was a typo about it:
there is no `country_id` field on the `payment.transaction` model,
it's `partner_country_id`.
Therefore, the computed fees according to the country
were not always correctly computed.
e.g. for Paypal, where the domestic fees
are lower than the international fees, it always
computed the fees as international.
opw-651778
Payment transactions referenceis have a unique constraint which was problematic when a payment was cancelled from the acquirer's page.
To stick the to DRY principle, I factorized a method that checks for existing references and happens a numerical suffix if necessary.
This was already implemented in website_payment but was moved to payment and used in website_sale.
Fees were not recomputed when the amount or the acquirer of the
payment transaction was changed.
This can happen if the user clicks on
"Pay now", which creates the transaction and computes
the fees for the first time and then redirects
to the payment provider, and then the user
came back from the payment provider, hitting the previous
button in his browser, for instance, and then
changes the content of his cart (the quantity, or even
the products) or change of payment provider
(from Ogone to Paypal, for instance).
opw-649509
merge *ALL* the dicts
The form rendering used to receive a dict for partner information and a dict for tx information and to transmit another dict to the qweb template; now everything is done in a single dict
Thibault Delavallée