- The name of the field `provider_id` on `payment.token` should not be
"provider Account" but "Provider".
- The computation of the display name of tokens crashed when the field
`payment_details` was empty.
- The form view of tokens missed a <group/> element to better display
the fields.
closesodoo/odoo#103621
X-original-commit: ae4079807d29996f4edfd295dcfa194973ada8db
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
A) Share a payment link and pay with PayU Latam (you'll be redirected
to their checkout page)
B) Make sure that your first payment attempt with Pay U Latam fails
(they provide the cards info to simulate successful and failed
payments)
C) After the first failed attempt, stay on the same checkout page and
do a second attempt (this time a successful attempt)
D) Click on 'Go back to the website of the shop' (still on the
checkout page).
Current behavior:
Odoo will show 'Your payment has been canceled'
Expected behvavior:
Odoo will show 'Your payment has been confirmed'
Explanation:
After the first payment failure payulatam calls the webhook to cancel the
transaction but after it lets the user the possibilty to retry the same
payment again and if the payment succeed it calls the webhook again to
confirm the transaction but it can not as the transaction is already in
a canceled state. To prevent this issue we allow the payulatam webhook
to set the transaction from canceled to done by adding canceled in the
allowed states of _set_done()
opw-2994527
closesodoo/odoo#103066
X-original-commit: 162b4a4fb958b8568a2d99625934b9b4f4dfa103
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit a constraint between the `ir_ui_view` and
`payment_provider` view made impossible for providers to be
uninstalled. After this commit the constraint is correctly treated.
A similar issue is found on a constraint on the `payment_custom`
module. To fix this and future possible problems we added the
possibility to modify the way providers are uninstalled following
each provider needs.
Task - 3002532
closesodoo/odoo#102951
X-original-commit: 56318826b758f09782c8f67c05a7a46789cff47d
Related: odoo/documentation#2802
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
The confirmation message for the sale order appeared twice in the
chatter: first with the confirmation and second with the posted payment.
The second message is now rephrased in order to avoid any confusion for
the user (no double payment).
task-2965158
closesodoo/odoo#101921
X-original-commit: c1faff69db2a66e249bfbc5ea77644da0957d401
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@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>
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 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>
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 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>
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>
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>
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>
Users can now ask for a refund from Odoo for their transactions done
through Authorize.net. A refund will be triggered from Odoo when
necessary.
Only full refunds are possible.
Note that unsettled transactions will be voided as they cannot be
refunded.
Task - 2678757
closesodoo/odoo#92279
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Computing the fields instead of storing them allows to implement the
feature for each provider more easily, without needing a migration
script.
task-2841744
closesodoo/odoo#91961
Related: odoo/enterprise#27618
Related: odoo/upgrade#3535
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, users may saw the capture and void buttons but
couldn't use them.
As capture or void actions need to access acquirer-related fields,
these actions are now sudoed to allow any users that see the button
to use it.
The access rules and rights are also checked before executing the action
to avoid abusive RPC calls.
task-2785144
closesodoo/odoo#91923
X-original-commit: 2e351d6ff9b7f72b486e83c827ff6e15a05c3331
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a 'manual capture' is set for Authorize.net and a client
make a payment in several partial payments the user can capture
all the authorized transactions without crashing now.
Task - 2676914
closesodoo/odoo#90212
X-original-commit: 68b354f7353e3b5fd1faaad1b762c3c73a286f0f
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>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Current behavior:
Public user have access to payment method that require tokenization wich leads to error when they use it.
We should not show those payment methos to the public users (e.g We shouldn't show sepa direct debit because this method uses tokenization)
Steps to reproduce:
- Activate SEPA Direct Debit in the payment acquierers
- Select Bank as payment journal
- In the bank payment journal create an account number (e.g BE71096123456769), and select a Bank (e.g BNP)
- Create a new customer (type : company, country : spain, and an email)
- Create a quotation with this new customer
- Click on the "action" icon and click on generate payment link
- Open the link in an incognito window (to make sure you'r not connected in Odoo)
- Try to use the sepa direct debit
- An access error appears because public user do not have access to payment.token.
opw-2754505
closesodoo/odoo#86415
X-original-commit: 2a084c4810c6d1af82901882d1588c8449ebdc78
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Whenever making a refund for a transaction with a saved token
the token will appear also on the refund transaction.
It is useful to keep track of which token was used in each
transaction, this remains true for refunds.
The token will also appear on the payments.
Task - 2694760
closesodoo/odoo#85484
X-original-commit: 351812a81ec29fe96bf3766c45ea3b51f4055066
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit lighten payment onboarding form in order to take advantage
of the Stripe Connect Onboarding Flow. It integrates the Stripe
Onboarding using the IAP proxy.
Purpose
=======
Help users easily onboard with Stripe by using the Stripe Connect API.
Specifications
==============
During the payment onboarding, if the user selects Stripe, they will
start the Stripe Onboarding. (NB: The process uses a proxy that handles
the Stripe Onboarding calls and signs them with the Stripe Connect key)
1) A call is made through the proxy to get the Stripe account token;
2) A call is made through the proxy to get the Stripe account link which
contains the URL of the Onboarding;
3) The user is redirected to the Stripe Onboarding;
4) The user completes the Stripe Onboarding;
5) The user comes back to the acquirer form of Stripe and is able to get
their keys.
6) The user can directly create their webhook after having copied/pasted
their API keys.
During the website sale onboarding, the user doesn't go through the
onboarding wizard but is directly prompted to activate their account.
Note that the Onboarding status isn't stored in the database so there is
no call to Stripe API to validate the account status.
API Documentation :
- Connect Onboarding: https://stripe.com/docs/connect/standard-accounts
- Webhook creation: https://stripe.com/docs/api/webhook_endpoints/create
task-2685160
task-2691213
closesodoo/odoo#84639
X-original-commit: 085f4af4e57c43127413585a8df5b3aa47843339
Related: odoo/enterprise#24376
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Antoine Vandevenne (anv)