This commit addresses an issue with the checkout form displayed on the
portal page of the Subscriptions app: when only one payment provider was
available for checkout, and it required an inline form to be displayed,
the latter would not be shown, and customers were able to hit the "Pay"
button, resulting in a client error. The problem was that Subscriptions
now simultaneously displays two payment forms on the same page, one for
checkout and one for managing payment methods, which was not supported
by the payment engine.
closesodoo/odoo#120482
X-original-commit: 91d701e34a25d2ceada1679f36a9cdbb96c6c019
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
avoid overriding payment views by creating new computed field in the payment provider property and override it if needed in inherited payment models
task-3120983
closesodoo/odoo#116573
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible to partially capture a
transaction from Odoo, and doing so in the provider backend would often
result in a full capture in Odoo when capture was supported.
With this commit, partial captures are made available in Odoo directly
from the sales order or invoice, for providers that support them.
Provider can either only support full capture or also support partial
ones. It also optionally managed the automatic void of the remaining
amount at the user request when multiple captures are supported by the
provider.
As of now, the only acquirer allowing partial capture is Adyen.
task-2728768
closesodoo/odoo#87251
Related: odoo/enterprise#35205
Related: odoo/documentation#2063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently there is no distinction between saved tokens and providers
and there is no info on tokens under what provider they were created.
When client has more than one token it looks messy and counters the
point of token existance. Now tokens have their creation date,provider
and are no longer in the same card as providers.
task-2510973
closesodoo/odoo#108260
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The payment values in the Qweb context of sale, sale_subscription and
website_sale were computed separately, although there is a large common
basis. This split made it hard to communicate between modules and
generated a lot of duplicates. The new function `_get_payment_values`
in sales is now used as a common basis method for all sale_* modules to
get the common payment values.
closesodoo/odoo#107788
Related: odoo/enterprise#34922
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Before this commit, when using express checkout, the shipping address
was requested only if the technical module 'delivery' was installed.
Now, over express checkout, the shipping address will be requested if
the sale order contains products that aren't services.
task-3149536
closesodoo/odoo#111796
X-original-commit: 9c16e83336b042ab77c267607ac43e0ef0db9997
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Payment methods without image or without name does not make any sense.
Previously created payment methods without a name will be
given default name and ones without an image will be deleted.
Payment icon can no longer be created or edited from payment
provider form view.
task-2853424
closesodoo/odoo#105909
Related: odoo/upgrade#4043
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
before this commit, from the payment providers menu, even though the provider is not installed in the database, the company, website and image fields are editable for the users.
after this commit, the fields will be editable/visible only after the provider is installed in the db.
publish/unpublish button will be shown only when provider is installed.
closesodoo/odoo#110114
X-original-commit: e910dee3ce4b526aa956ad489e83442b3a425c36
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the lists of supported currencies by payment
provider were hard-coded in the Python scripts, which made them
unavailable to the users.
With this commit, the implemented initial lists of supported currencies
are displayed on the form view and are editable, because Odoo lists may
not be up-to-date. Empty lists do not trigger any filtering on the
payment providers to access payment methods.
For Authorize.net and Asiapay payment providers, the specific
`(authorize,asiapay)_currency_id` are removed and the generic payment
provider field `available_currency_ids` is restricted to a single-item
list when one of those providers is enabled.
task-2926016
closesodoo/odoo#101018
Related: odoo/enterprise#34158
Related: odoo/documentation#2788
Related: odoo/upgrade#4069
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Payment fees appeared as float (and not monetary) in the Payment
provider form and were not converted into the chosen payment
currency.
Some tests check the `_compute_fees` function.
task-2854143
closesodoo/odoo#100156
Related: odoo/upgrade#4106
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
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>
"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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
Users without the right permission see the buttons but can't use them.
Capture and void buttons are now only visible and usable for admin or
users in account.group_account_invoice group (for invoicing module).
task-2785144
X-original-commit: db6b54cc49ba7d9266e766112017604ed98c2cb3
Part-of: odoo/odoo#91923
*: 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>
This commit uses the `is_html_empty` util method to detect empty HTML
fields in cleaner and more resilient fashion than what was done in
808cc53bb02b0f1851a2a229bd5235a5fb944408.
closesodoo/odoo#84999
X-original-commit: 89f3aa8a979c5236b587f9690595117b52f0dd63
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, an empty line would be shown in the payment forms on
the card of each payment acquirer whose `pre_msg` field was not empty.
This is because displaying this HTML field in a form view and saving it
causes the value `<p><br></p>` to be written on the field, even if it
was left empty. The same issue occurred with the `pending_msg`,
`auth_msg`, `done_msg`, and `cancel_msg` fields that are shown on the
portal of some apps (Sales, Accounting...).
With this commit, the value of these fields is tested before displaying
them. If the value is `<p><br></p>`, the field is not displayed, hence
avoiding to display a blank line.
closesodoo/odoo#84755
X-original-commit: 808cc53bb02b0f1851a2a229bd5235a5fb944408
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: mrp_subcontracting_purchase,payment,purchase_(stock)
BEFORE THIS COMMIT
fa-shopping-cart was used for different purchase-related contexts.
This icon should only be used for online shopping / ecommerce.
AFTER THIS COMMIT
Wa make sure one icon is used for one concept.
- fa-shopping-cart : ecommerce / add to cart
- fa-credit-card : purchases
- fa-credit-card-alt : replaces other uses of fa-credit-card
- fa-pencil-square-o : quotations in marketing modules
Icons are updated accordingly. Other icons are also changed to
increase readablity.
--- Links ---
Task Id - 2593306
COM PR - odoo/odoo#75694
ENT PR - odoo/enterprise#20478
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, it was not possible to refund a payment from Odoo.
Users had to go through the payment acquirer's backend and update the
payment accordingly in Odoo.
With this commit, refunds are made available in Odoo directly from the
payment form, for acquirers that support them. Acquirer can either only
support full refunds or also support partial refunds.
As of now, the only acquirer allowing refunds is Adyen, with partial
refund support.
task-2527891
closesodoo/odoo#70881
Related: odoo/upgrade#2689
Related: odoo/enterprise#19829
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
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>
Arnaud Joset