The alert block content and style for the transaction status after
payment were computed in two different places: In the dedicated
`payment.transaction_status` QWeb template, and in the
/payment/confirmation` route's controller which, for some reason, was
re-inventing the wheel instead of relying on the dedicated template.
This commit combines the slightly different behaviors in the template
and gets rid of the duplicated logic in the controller to:
- Handle the states 'draft' and 'error'.
- Always show the transaction's state message, and not only when the
transaction was in a state for which there exists no pre-defined
message (`draft` and `error`).
task-2924873
closesodoo/odoo#96348
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a customers paid a transaction through the `/payment/pay` route and
the transaction was authorized, the message for confirmed transactions
would be shown on the `/payment/confirmation` route instead of the one
specific to authorized transactions.
task-2527323
closesodoo/odoo#78843
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Due to an oversight, the "Save my payment details" checkbox was shown on
the inline payment form of SEPA Direct Debit acquirers, which should
never happen because the transaction is *always* tokenized with those.
With this commit, the `_is_tokenization_required` method is slightly
refactored to read the provider from the current `payment.acquirer`
record rather than from the kwargs. This conveniently fixes the issue
and prevents it from happening again elsewhere.
closesodoo/odoo#95519
X-original-commit: ebeebd87ed6d687b96dda3006b81356dfa76d0a0
Related: odoo/enterprise#29237
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the reference of a validation transaction followed
this format: “validation-20220222072710”, which did not match the
standard format for refund transactions (”R-S000001”). Moreover, some
providers limit the length of transaction references which forced us to
truncate the quite long reference.
With this commit, future validation transactions will have a reference of
the format: “V-20220222072710”.
task-2830826
closesodoo/odoo#94921
Related: odoo/enterprise#29076
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the /payment/pay page would not filter out acquirers
configured to allow tokenization when it was although required for the
payment. For example, for sales order with a subscription product (which
requires tokenization), acquirers that don't allow tokenization would be
shown to the customer if they pay from the /payment/pay page, but not if
they pay from the portal view of the SO.
This commit makes sure the sales order id is correctly propagated to the
Subscription app which then flags the payment as requiring tokenization.
closesodoo/odoo#86202
X-original-commit: 9ab7b2447f2ece46f1a25335ab76f06323f03d22
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Current behavior :
In a multi-company environnement if you generate a payment link and access it from incognito page the company was always the logo of the first company.
Steps to reproduce :
- Get in a multicompany environnement
- Create a invoice in company B
- Generate the payment link in the action menu
- Access the link in incognito mode
- The company logo is always the logo from company A
opw-2756438
closesodoo/odoo#85000
X-original-commit: 0e2e79d055e8565e2913b30477fcfdb71e99bdae
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Expected behavior :
User should be able to archive the tokens he sees
Current behavior :
User sees his tokens but cannot archive a token from another company
Steps to reproduce :
- Install Sales & Contacts
- Create a 2nd Company
- Enable `Online Payments`
- Setup a Payment Acquirer (Test Mode for current company) *Be sure to have `Allow Saving Payment Methods` checked*
- Create a new contact and grant him portal access
*With new contact*
- Get the link and set a password
- Create a new payment method in `Manage payment methods`
*With admin again*
- Replace `Allowed Companies` and `Default Company` for the new contact by the company created before
*With new contact*
- Go back in `Manage payment methods` and try to delete the token
Reason :
Before, the `write` method from the model was called but returned an AccessError because the token was linked to another company.
Now a custom route is called, it checks if the token is linked to the user and archives it with the necessary rights
OPW-2660186
closesodoo/odoo#82405
X-original-commit: 19f8c4e26291740edecd0c101c3d331deef2758d
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
... even if they are in a company in which he has no access rights.
Finetuning of #79253 to keep previous multi-company behavior.
We didn't consider the fact that the previous behavior was fully managed
in sudo (through request.env.user.partner, which gives a sudoed record)
and changed the behavior by using an unsudoed search.
closesodoo/odoo#80694
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Saved payments methods for disabled acquirers are no longer visible on the customer
portal. It was fustrating for the customer to see saved payment methods that he was
no longer able to use as they are disabled.
Now the use should only be able to see payment methods that he can indeed use.
Task - 2679695
closesodoo/odoo#79253
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a payment is made, add required parameters to the landing route.
This issue was introduced with 7fccbac
task-2645216
X-original-commit: cfcf4c64caac951783a1b39b63c024028b07b434
Part-of: odoo/odoo#77874
Co-authored-by: Victor Feyens<vfe@odoo.com>
This commit adds /donation/* routes to perform the donation:
- /pay: shows the form with the contact details and donation details
- /transaction: creates the partner_id if missing and executes the
transaction
- /confirm: displays the payment success page
PR-63133
task-2398403
Part-of: odoo/odoo#63133
Before this commit, the validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Before this commit, it was not possible for an acquirer to support
tokenization while not supporting validation because the acquirer would
be thought to be compatible with either flow based on the
`support_tokenization` field. This was a false assumption because some
acquirers, such as Ogone, can offer to tokenize a payment method in
payment with redirection flow while not allowing tokenizing a payment
method for future usage, without payment.
Note that this was not an issue for acquirers supporting the direct
payment flow because they could either support validation natively, or
seamlessly charge a small amount and refund it immediately to tokenize a
payment method.
This commit makes it possible for a module implementing the validation
operation to filter acquirers based on whether they support it,
regardless of their support for tokenization.
task-2494916
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Select a sales order.
Go to action > generate payment link.
Open private browser, reach the link.
User will receive error message because of access denied to the
res.partner data.
opw-2287534
closesodoo/odoo#54808
X-original-commit: 3b4f3a8ad2880721cf6de9fb08387412df85d356
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install 3 payment providers:
P1: no countries set
P2: country set to USA
P3: country set to Canada
- Activate online payment of invoices
- Create an invoice for portal user A (country of user is USA)
- Login with A
- Pay the invoice
All 3 providers are available, while only 1 & 2 should be available.
The providers are filtered in the sale module, but not in the account
module:
https://github.com/odoo/odoo/blob/586ee04a6296c13868011b3afaca61be5c6ff3c6/addons/sale/controllers/portal.py#L190-L193
The same issue occurs with the direct link `/website_payment/pay`.
We apply the same filtering in all modules.
opw-2279710
closesodoo/odoo#53483
X-original-commit: aaac93b551e2a5f331dd14ee5aefbe4ced173691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce:
- install sales, ecommerce and payment_authorize
- setup authorize.net (test mode)
- go to sales and select the quotation S00007 (demo data) or create a quotation
with multiple items that add up to a float
- select action > generate a payment link > go to the link > select pay with authorize
- you are redirected to authorize.net use 4111 1111 1111 1111 as card number and 1223
as expiration date > pay
- you are redirected to the odoo payment process page
- wait for the result
Previous behavior:
the user is returned to a 404 error page but the payment went trough
Current behavior:
access_token generation is consistent and will not fail because of
float representation
the user is returned to the "payment confirmed" page
WARNINGS:
- watching the values in vscode prevents bug reproduction
- when setting up authorize.net, do not forget to add your test url to
the account's allowed return urls
- use https for authorize.net connection
opw-2223135
closesodoo/odoo#50633
X-original-commit: 0fe7fa0f95b7393d8829ba4b216d6c41d0c0dc3d
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
- The payment link generated by using the wizard
`payment.link.wizard` are overriden to generate
URL linked to sale orders.
If so, we want the payment acquirer displayed to
be in the same company as the sale order.
closesodoo/odoo#49018
X-original-commit: 8c299efb6cb4355cec39cdedd8d7c3134f53d199
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
The access right on payment_token is based on the partner_id
linked with the user
If there is token link with the public user,
they are shown for every request were the partner_id is not defined
If you are logged with an internal user with sales access right,
you'll see all the payment_token linked with the acquirer
We should avoid both situation and show only the payment_token
from the legit partner_id
the one of the current user or the one given as parameter
closesodoo/odoo#44346
X-original-commit: 9edad5d9018ae357e955a5e21e9366e56caa8e31
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
Fix error like "TypeError: {4} is not JSON serializable" when
serializing the session object (e.g. for external storage)
closesodoo/odoo#41360
X-original-commit: e91e38fa4bd12ba9d2027e7778a10252e08b9a86
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- allow acquirers to arbitrarily include info about the tx in the
processing page
- pending is now a valid state that could require customer action in the
payment processing page - don't blindly redirect to the return url of
another tx if a pending transaction is there
This latest change might mean that customers with many tx attempts might
have a sub-par experience as they may need to click manually on the
redirect url of a successful tx while before they were redirected
immediately.
When generating a link for a payment through the website_payment/pay
route, including the partner_id 'blindly' is somewhat of a security
issue since it means you could potentially create payments for any
partner of your choosing.
This commit instead introduces an access token mechanism where the
partner_id, amount and currency_id are used to generate a unique access
token that can be checked upon accessing the payment page. This token
is only checked if the partner_id field is set (otherwise this is just
an anonymous payment like any other).
Currently when payment is processed through the payment link by
public user then there is no details of partner(email, country etc..)
so due to that some payment provider(paypal, stripe etc.) produce
the traceback on public payment
so when generating link for the payment pass the partner on link so
where payment is processed by public user then it will get the customer
of the record as partner, so on behalf of the customer the payment is
processed.
task-1938635
Closes: #31575
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
Victor Feyens