Steps to reproduce:
- create and send a quotation
- make a failed payment (through cutomer preview)
- create and send a second quotation to the same customer
- make a succesful payment this time
- redirect takes to the wrong quotation (failed one)
Bug:
polling the processed payments initially returns both transaction
but the following polls only returns the rejected payment
(introduced in [1] processed transactions are filtered out)
since there's only a single transaction, redirect takes to it
Fix:
if there's only a single succesful transaction (regardless of the rest)
it means the current payment was successfull so we redirect to it
opw-2954162
[1]:https://github.com/odoo/odoo/pull/31741/commits/7612659565ee24f1c878b81e6c86b5780fbd5a3dclosesodoo/odoo#101252
X-original-commit: 6ea920d2573cf68c6a5cbaf1f6af31fd7de155ff
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Method `_compute_reference` computes unique reference for a transaction. If
reference from `account.move`'s `payment_reference` was never used, the method
just returns that reference. Othwerwise it adds a counter. The latter requires
to make a regular expression to count records with the same prefix. However, if
the prefix has special regexp characters (e.g. `+++INV/2020/666+++`), then we
have to escape the characters first. This is what this commit does.
opw-2994126
closesodoo/odoo#101201
X-original-commit: 6c513d43eba8c58171b0fb632d0ac82b28aa9e7d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
*: adyen, authorize, demo, razorpay, stripe.
The param `create_refund_transaction` from `_send_refund_request` became
useless following this commit:
https://github.com/odoo/odoo/commit/e4c63126b45854b10f08ab14dee5eb1d4ed98bb0
It was only used for Authorize.net, which now works without calling this
param.
task-2869910
closesodoo/odoo#101105
X-original-commit: 6855d65df7a83037ee5e2202966fa4e67dae7d5a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Use generic method on_delete instead of personalized one for the sake of
clarity and reproductibility.
task-2883630
closesodoo/odoo#99958
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit removes unused imports and renames some confusing variable
names and helper texts that were changed with commit f7b8f075 when
renaming the term "acquirer" to "provider".
closesodoo/odoo#100348
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Avoid starting the patcher two times to not create two separate
instances of it, and only stopping one of it.
closesodoo/odoo#100058
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The module `payment_transfer` was originally meant to implement a
payment with Wire Transfer flow, which it does not exactly do since all
it does it making transactions follow the payment flow until their
`pending_msg` field's content is shown to the customer. Because of that,
other modules (`website_delivery_ups`, `website_sale_picking`) started
duplicating the base acquirer Wire Transfer to create new payment modes
such as Cash on Delivery and Pay in Store.
To better prepare for a proper dinstinction of the custom modes enabled
by other modules, this commit renames the module `payment_transfer` to
`payment_custom`.
The module `payment_transfer`'s `auto-install` key is also set to
`False` since we no longer want Wire Transfer to be the default payment
acquirer for new databases.
task-2853489
Part-of: odoo/odoo#99400
The name "Payment Acquirer Test" of the acquirer bundled with the module
`payment_test` is confusing. It is actually the only acquirer that
doesn't connect to a test API, and its purpose is not to make test
transactions but to showcase the integration of other apps (Accounting,
Sales, eCommerce, Subscriptions) with demo payments.
Hence, the module is renamed to `payment_demo` along with its data and
technical keys to better make the distinction between acquirers' test
environment and demo payments.
task-2853481
closesodoo/odoo#99397
Related: odoo/upgrade#3846
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The four payment acquirers implemented with these modules all present
a subset of the following issues:
- The user experience for the payment step is really bad: All of them.
- The API is poorly documented, breaks often, or is badly designed and
hard to work with: All of them.
- It is no longer possible to open a new account: PayULatam, PayU money.
- The countries/payment methods/currencies coverage is limited: Alipay,
PayU money.
- It is not possible to implement additional features such as
tokenization, manual capture, or refunds: Alipay, PayULatam,
PayU money.
- They have a better replacement already available in Odoo: All of them.
This commit thus deprecates the above-mentioned payment acquirers. This
means that their module can no longer be installed on new databases and
alternatives are suggested. Existing databases in which the modules were
already installed will keep working.
task-2806832
closesodoo/odoo#99025
Related: odoo/upgrade#3848
Related: odoo/documentation#2686
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The present kanban view of acquirers is not the most appealing
one. It is full of useless information (e.g. "online payment") and the
combination of provider logos makes it look "old".
After this commit, the kanban view will hopefully have a "cool" and
concise look simular to the "Apps"'s kanban view.
Task - 284171
closesodoo/odoo#98345
Related: odoo/enterprise#30585
Related: odoo/upgrade#3803
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit enables eCommerce customers to pay with the express payment
methods Apple Pay and Google Pay from the cart page.
For the moment, only Stripe supports this additional feature but it
was designed to make it easy to implement with a new provider.
task-2754209
closesodoo/odoo#88374
Related: odoo/enterprise#29915
Related: odoo/documentation#2392
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Mercado Pago is the largest online payment platform in Latin America,
supports more countries, currencies and payment methods in the region
than other PSPs, and is more accessible to small businesses.
This commit integrates Odoo with a combination of the Checkout Pro and
Checkout API solutions of Mercado Pago to implement payments with
redirection to the provider's payment page.
Task - 2704764
Part-of: odoo/odoo#83957
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, customers never waited on the status page for their
payment to be confirmed. Instead, they were redirected to the landing
route before that the transaction reaches a final state.
Although this bug is present since version 15.0, it not considered as a
problem worth fixing in stable since redirecting customers in advance is
already supported. It is fixed in master to lay ground for further work
that will require customers to wait for the payment confirmation.
After this commit, customers will remain on the status page until their
transaction state is updated to a final state ('authorized', 'done',
'error'). An exception is made for Wire Transfer's payments that are
never confirmed and should not block the customer on the status page.
task-2908493
closesodoo/odoo#95933
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, tokens were prefixed with usually 12 X’s. To improve
readability, modernity and to shorten the length, this commit changes
token prefixes to a standard of •••• 1111.
task-2832669
closesodoo/odoo#94978
Related: odoo/upgrade#3738
Related: odoo/enterprise#29190
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The message returned by `_get_sent_message` for validation transaction
was wrong, refering to a token, but there is no token on validation transactions.
This doesn't have to be fixed in stable since validation transactions are not linked to
any specific document, so the wrong message was never posted anywhere.
Now that we improve the display logic of payment tokens and noticed the problem,
this commit fixes it (for code consistency, and if any custom code/... uses this
message as well.
Part-of: odoo/odoo#94978
This rule has no effect for a while!
In settings, we had to delete it because converting it would add
space in the first column.
In payment, it seems that this offset was used to center the content.
We prefer to convert it.
closesodoo/odoo#98438
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Calling `_build_url` for a test class that only inherited from
`PaymentCommon` would raise an error, as the method depends on the
`HttpCase` test class that is only inherited by `PaymentHttpCommon`.
closesodoo/odoo#95860
Related: odoo/documentation#2532
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The button should only be shown if a tokenization-capable acquirer is
enabled (or if a token already exists), but a typo made the button being
shown regardless of that (first) condition.
closesodoo/odoo#97276
X-original-commit: b301844cbdcb07b4e13186cae85257b18ca54654
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When making transaction with 'validation' type and where fees
were active, fees were added to the amount.
This behaviour is problematic because
validation operations are used for tokenization for example where
no credit should charged to the customer.
Now validation operations have no fees even if fees are active
on the acquirer.
Task - 2784765
closesodoo/odoo#96712
X-original-commit: 69b04e753ab4e90e68b9d3e678ebea277586e7ac
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The csrf token given to the assignTokenRoute is not necessary
and will trigger warnings in the logs.
closesodoo/odoo#94020
Related: odoo/enterprise#28595
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
Before this commit, it was impossible to migrate from one payment
acquirer to another as the only way to do so was to change a payment
acquirer’s state to ‘disabled’, subsequently disabling all tokens of that
acquirer (detrimental for eg. running subscriptions).
After this commit, payment acquirers have an additional boolean
‘Published’. With this functionality, users can safely migrate by
keeping an acquirer ‘enabled’, but invisible for customers.
There are five combined states an acquirer can take:
‘enabled’ & ‘published’: Visible to all users
‘enabled’ & ‘unpublished’: Visible only to internal users
‘disabled’ & ‘unpublished’: Same as previously ‘disabled’
‘test’ & ‘published’: Same as previously ‘test’
‘test’ & ‘unpublished’: visible only to internal users
task-2871459
closesodoo/odoo#94242
Related: odoo/upgrade#3688
Related: odoo/documentation#2308
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>
Before this commit, zombie payment tokens (= tokens linked to disabled
acquirers) could still
1) be used by internal users and
2) reactivated when the acquirer’s state changed to ‘test’ or ‘enabled’.
This is not desirable because zombie tokens should neither be used,
nor reactivated.
After this commit, all tokens related to an acquirer are unassigned
from linked documents and archived as soon as the acquirer’s state is
changed to ‘disabled’. Creating a payment with an archived token is
prohibited. In addition, archived tokens cannot be un-archived anymore.
task-2649806
closesodoo/odoo#93774
Related: odoo/enterprise#28661
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Sometime Paypal took 3 or 4 days for some payment verification due to
weekend. This raises the retry limit days for 4 days instead of 2 to
solve the issue
closesodoo/odoo#95522
X-original-commit: 5aaaaf8f072b3f8ab66a269bb3dba02714b593ad
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>
Hide the 'Pay Now' button for invoices which transactions total amount
equals their total amount.
When the total amount of all transactions related to the invoice is
equal to or greater than the total amount of said invoice, the 'Pay Now'
button should no longer be displayed.
task-2527323
closesodoo/odoo#95262
X-original-commit: de81225d39e7951ea9a63e24bab3a0138a6942e3
Signed-off-by: Achraf <abz@odoo.com>
After the payment apocalypse, `payment_test` was cleaned and stripped of
all useless parts. It was a very basic testing acquirer that allowed to
enter fake arbitrary payment details, choose whether they should be
tokenized, and then pay. It was intended to test the payment flow of
various applications (Sales, Subscriptions, Invoicing, ...) for a single
scenario: successful payments with immediate capture.
In order to extensively test an app's payment flow (explore other
scenarios), we need `payment_test` to have additional features.
Now, `payment_test` will allow profound testing of these features:
- separate authorization and capture
- customer fees computation
- tokenization
- refunds
- on the /pay page, users will be able to select the status of the
payment
- on the payment transaction form view, users can change the status of
a payment 'pending' to either succeed or fail
- on the payment token form view, users can change the state of future
transactions made with that token
task-2512196
closesodoo/odoo#78083
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: xlu-odoo <xlu@odoo.com>
Some payment tests were unexpectedly relying on the 'transfer' payment acquirer
to work because of a multi-company issue in the core payment tests setup.
This commit fixes the problem and adds an additional check in the tests to
make sure they rely correctly on the 'dummy' acquirer created in the payment
tests common.
closesodoo/odoo#94972
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Christophe Monniez