The currency_field shouldn't have to be specified in the view if it has
the same value as the field specification in python.
closesodoo/odoo#107396
X-original-commit: 47cf3688baf6aed6f027fc44db7293d9563789f4
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Steps to reproduce:
1- install ecommerce - payment_stripe
2- configure stripe testing credentials
3- edit main currency to have more decimal places (assume 4 instead
of 2 for USD)
4- add product p to cart (assume p.price = 100 USD)
5- checkout with stripe
6- the price is 10,000 USD instead of 100 USD
Bug:
Stripe expects the amount in the smallest unit possible for the
currency. https://stripe.com/docs/currencies#zero-decimal
This differs from a currency to another according to
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
`to_minor_currency_units` uses the decimal places of the currency by
default which will produce wrong values
Fix:
use currency exponent table built from
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
default behavior (for a currency that is not available) is not changed
OPW-3058173
closesodoo/odoo#106936
X-original-commit: 703ed2b4e162ff0a7b621e3cf8b92b8eb7fddff8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Rather than hiding all payment providers and payment tokens from the
payment form, a warning is now shown to the user if their company is
not the same as that of the document (SO, invoice, ...) they're paying
for.
task-2983985
closesodoo/odoo#100375
Related: odoo/enterprise#31424
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- install the "Subscriptions" module;
- create a subscription;
- got to the portal of the customer of the subscription;
- click on the "Set/Manage Payment Method" buton;
- add a new payment method.
Issue:
An invoice is generated and therefore the next invoice date is incremented.
Cause:
We do not check the type of operation when we finalize the payment process.
And so a subscription renewal invoice is created.
Solution:
Transactions with "operation" which is equal to "validation" are for tokenizer only (without payment).
If "operation" is equal to "online_token", it is a payement which must be invoiced.
Detect payment token change, if this is the case to not generate an invoice.
opw-3061621
closesodoo/odoo#106300
X-original-commit: 29bfe42904af485614ef8546490dc2ed31ecc785
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
"Demo token" badge is only displayed for tokens created under Demo provider.
This is misleading and should be connected with provider state not it's name.
It should be shown on every token created under "test mode".
task-2908903
closesodoo/odoo#101937
Related: odoo/upgrade#4023
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
traceback is raised in settings page and on clicking activate stripe button after deleting the paypal payment provider from the database
closesodoo/odoo#105692
X-original-commit: 4d34606baf314c78d608904720778ff2ac6bf5b4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The confirmation dialog to delete a token from a portal user is the
same whatever the linked records. This part of the code is now moved to
a separate function `_buildConfirmationDialog` in order to allow
overrides of the method in particular cases (e.g. Subscriptions).
task-3048269
closesodoo/odoo#105289
X-original-commit: 51d6b724f061af44bc07c342dfa9a34b4d1a2101
Related: odoo/enterprise#33741
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Since the generated payment link is not editable, it is hidden behind
the wizard copy button.
To help the users understand the button, the text on the button can now
be edited in the xml with a `label` attribute.
task-2683480
closesodoo/odoo#100261
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
Payment tokens should not be created manually, as it is useless,
confusing and potentially harmful. They should only be created alongside
payment details of a customer payment method.
task-2848379
closesodoo/odoo#99915
Related: odoo/enterprise#31199
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
- 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>
Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing
Issue:
When using the register payment with a token with any of the payment acquirers,
if there is a concurrent access error during the reconciliation process,
the payment intent is sent multiple times to the acquirer, making the card charged multiple times.
Steps to reproduce:
-Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing
-Configure Stripe with your public and secret key (2FA is now enforced for Stripe accounts, therefore,
we don't have a generic test account anymore. You have to create your own.It is quite fast and easy to do)
-Have a portal user PU with an already registered payment token PT
-Go to Invoicing
-Create a new invoice I:
-Customer PU
-Add anything in invoice lines
-Confirm I
-Register a payment for I:
-Journal: Stripe
-Saved Payment token: PT
AT THIS STEP, YOU MUST ENSURE A CONCURRENT ACCESS ERROR WILL RAISE DURING THE RECONCILIATION
-Create Payment
Log analysis:
A first payment intent is sent to Stripe. The card is charged and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment intent is sent again to Stripe, The card is charged AGAIN and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
For each retry, the intent is sent and the card is charged.
If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Stripe's side and the card will be charged 3 times.
This PR mitigate this behaviour.
It doesn't address the root cause but by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent mutliple payments to happen.
OPW-2662964
closesodoo/odoo#103515
X-original-commit: 5fe1c1bbba4d754eed7e8927b82752969d6f563d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Skip the payment_asiapay test verifying the reference computation
with an invoice when account_payment is not installed.
Also add a dedicated helper, using the variable in payment already storing
whether the account_payment module is installed.
closesodoo/odoo#103449
X-original-commit: f1fd1c9e484025782079fc18c152269aa1723ed5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, most of these modules had a custom sequence
number intended to sort them in the Apps' kanban view. In reality, the
sort on the module name makes the custom sequence useless. This commit
thus sets all of these modules' sequences to `350`.
In an effort for uniformization, we also made names and summaries more
generic, and removed the descriptions which did not add any value.
Task - 2960976
closesodoo/odoo#103131
X-original-commit: 75397daa2fff1a027af7a3cb008e6cbc828645fc
Related: odoo/enterprise#32752
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fees charged by payment providers are shown when choosing a payment
option (provider or token) on a payment form.
Before this commit, the fees badge was not shown next to tokens, which
could be understood as fee-free.
With this commit, the fees badge will also appear next to tokens.
task-2854120
closesodoo/odoo#103100
X-original-commit: 9dded8b5fadf99379018446d9390e6f9510e8e80
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Due to migration from Bootstrap 4 to 5, rounded badges look bad. No
unification of badge styles, some are rounded and some are squared. Tags
style should be unified and adjusted for Bootstrap 5 with this commit.
task-3001057
closesodoo/odoo#103099
X-original-commit: 611e2f20f975c590eb75d64379be84dd4cc472ef
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>
When the payment views were updated with commit odoo/odoo@f7b8f075, a
hook was improperly renamed to `code`, which doesn't help to figure out
its purpose. This commit renames it to `provider_credentials` which
better fits its role.
While doing so, the view files are also renamed and/or split by model to
increase their readability.
closesodoo/odoo#102976
X-original-commit: 49d126d4fce18761d0261adac00e115b840b9b47
Related: odoo/enterprise#32662
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>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@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>
When [1] was merged, it did not adapt correctly external providers
redirections. As now the /shop pages can be viewed inside an iframe, the
external redirections must be opened in the top window.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102723
X-original-commit: 3a32b9e1efa6277b345dc9239334680651690df7
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
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>
Victor Feyens