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.
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
- replace the portal_sale blue ribbon by a website_portal_sale link from the portal home
- remove all fields and methods related to banner in portal_sale
- remove "validation" field in payment_acquirer since it was only used here
- general:
- add payment.method and payment.transaction menu in invoicing
- payment.acquirer:
- add image field
- add stat button to see payment.transaction objects
- payment.transaction:
- language field is now a selection instead of a char
- rename s2s_cb_eval field in callback_eval
- form view cleaning
- on_change_partner_id now fills in the partner details
- add an ir.sequence for transaction name
- add a many2one to payment.method
- country defaults to the country of the company
- payment.method:
- add a one2many to payment.transaction
- add a stat button to see payment.transaction objects
[IMP] website_quote: rename s2s_cb_eval payment.transaction field to callback_eval
[IMP] payment_* (all providers): add image data and rename s2s_cb_eval field to callback_eval
Better display of contacts, simplified contact creation, use default image
for shipping and delivery, and various fixes and improvements in the
form view.
Main impacted addons :
- account: add a bank_account_count field and stat button that replaces the
2many field
- base_vat: remove the button to check vat, as there is already a constraint
and removed and unused import
- payment: add a payment_method_count field and stat button that replaces
the 2many field
- website_sale_delivery : set the field website_published into a stat button and set the form into a sheet
- payment : Payment acquirers unpublished by default, and website_published set into a stat button
- website_partner : res_partner unpublished by default, to avoid partners as “Plusbelle LaPoubelle” to be published on the prod (True Story)
- website_sale_delivery : Delivery method unpublished by default. Adapt the demo data to be published (to avoid breaking a test), and set the field website_published into a stat button.
In the partner model, there is only one field `name`.
The first name and the last name are not within two
separated fields.
By assumption, the firstname is written before the last name
(first <> last)
This assumption should be kept when sending the
first name / last name of the partner to the payment acquirers
e.g. Paypal.
opw-643120
-->Company form view :
- Campany Tagline moved in the header, invisible if empty
- Partner field set in group_no_one
- Account Holder removed from tree view
- Intercompany rules tab/Responsible fields into group_no_one
-->Account res_config form view :
- Charts of account : code and #digits fields removed, as they depends of the country
and are configured in the datas
- Use Anglo Saxon checbox : Automatic, removed from the view
- tax_calculation_rounding_method field set automatically in the CoA : Removed
- Manage customer payments and follow-ups are enabled by default, so removed the option
NB : Some fields has been removed from the setting view because of legal issues and
also because they are automatically filled with the CoA.
If they have to be modified in some countries' CoA, they have to be added to the view
in these specific CoA, not is the standard view.
This commit adds a new model, Payment Method, which stores
a reference to the payment acquirer's database and a reference to
a partner. Each payment module must have its own implementation.
The implementation is completely abstract but may not suit every
provider's way of implementing recurring payments.
Commit 8a6e859 wrongly introduced this new field when adding the new
`payment_authorize` module.
As 8.0 is a [stable version](http://git.io/vfACM), no data model change
is allowed.
We convert this field to a `fields.dummy` in case someone installed (or
update) this module with this fields to ensure the view still applied
and is not broken.
The payment transactions references must be unique, but for
states within draft, pending, done states, not
if the transaction has been canceled or in error.
Otherwise, this is not possible to create a new payment
transaction for an ecommerce order for which
the payment has been canceled by the acquirer
For instance, when the customer lands on Ogone,
then hit the cancel button
opw-627914
Martin Geubelle