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>
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>
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>
Users who select Stripe as their payment acquirer will now have the
possibility to capture manually the amount later (e.g. when delivering
the product).
task-2278434
closesodoo/odoo#69598
Related: odoo/upgrade#3290
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>
This commit adds payment icon sequence to display the icon in a more
famous-more visible order.
task-2685160
X-original-commit: d11ff9eda43c390f584a148a956f7bc505007765
Part-of: odoo/odoo#84639
*: extensions of `adyen_platforms`, namely:
- pos_adyen: remove related code, records, views, ...
- payment_odoo: remove the module
- sale_payment_odoo: remove the module
Modules related to Odoo Payments are already all merged since 14.0 and
14.4 (depending on the module). As the plan is to merge the final
version of Odoo Payments in 15.0 soon after the release, we want to
avoid all the complications that inevitably come with huge diffs, model
changes, XMLID collisions, etc. when merging in a stable version. Even
though it is possible to install these modules since 14.0, no
information could be lost during the upgrade since the entry point of
the application has never been activated.
task-2637770
closesodoo/odoo#75852
Related: odoo/upgrade#2804
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Antoine Vandevenne (anv)
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.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>
If a merchants didn't enable a local Payment Method Type (PMT) on Stripe
side (such as bancontact), his customers eligible for it (ex.: Belgian
and paying in EUR) won't be able to pay using it.
This commit fixes this issue by adding a condition on the payment icons
assigned to Stripe: if the payment icon related to a given payment
method is not listed as a supported payment icon, the related payment
method is not offered to customers, unless the payment icon does not
exist at all.
User can enable PMTs through (Payment Acquirers > Stripe
> Configuration > Supported Payment Icons). This concerns: ideal,
bancontact, eps, giropay and p24.
This solution is not entirely satisfactory but it isn't possible to
fetch enabled PMT from Stripe.
opw-2335482
closesodoo/odoo#60740
X-original-commit: 1d0f23599bbd425c81131a5f6c1c22531ffcd0ee
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Install payment
Archive the cron
Upgrade system
--> Issue the cron is now active
Note: on testing server we archive cron (we make a an SQL query before upgrade the system)
@qdp-odoo
@nim-odoo
@sla-subteno-it
closesodoo/odoo#53658
X-original-commit: a47f0249d35da805436e33d06800988ca4c3b6a9
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Avoid trailing space:
In translation content, these tends to be skipped during translation,
making the message inconsistent. There is already a translation for
the term without the space so can reuse it.
Merge "setup"
Use the same writing to avoid having two similar messages
Remove unnecessary comma
Merge PayPal and Paypal
Courtesy of Primesh on Transifex
closesodoo/odoo#38348
X-original-commit: c1fb136cc684eba0cdeec302f27268ccda7fa5d2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The purpose of this commit is to expose SEPA Direct Debit acquirer to
the Odoo community edition. The dedicated module, though, is restricted
to the enterprise edition.
Minor changes in following modules:
- base: added ir.module.module record
- payment:
- added data to expose the new payment acquirer.
- added 'to_buy' field to track whether the payment acquirer is
restricted to enterprise users.
- allow multi word payment acquirer name. It was breaking on the first
underscore.
task-1870363
closesodoo/odoo#26427
The big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
This commit introduces the Alipay payment provider, a popular acquirer
in the Chinese market.
There are 2 possible ways to use this acquirer:
- express checkout mode (only available for merchants located in CN)
- standard checkout mode (availabe for foreign merchants)
Note that this provider does not support server-to-server payments,
tokenization or any other bells and whistles besides fees. There are no
specific behaviours related to this acquirer, it behaves like most 'form
based' payment acquirers with a form submission, s2s notification from
the provider as well as redirect in case the s2s did not reach the
server in time.
closesodoo/odoo#21855
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Change the label from PayUlatam to PayU Latam.
Hide s2s Form template field where Payment Flow is not s2s.
task-1940000
closes odoo#31048
closesodoo/odoo#31048
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This reverts commit f735951d5c.
Revert payment acquire due to the fact that the encryption scheme
is broken by design and therefore cannot be trusted.
closesodoo/odoo#31281
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
Description of the issue/feature this PR addresses:
Accessibility improvements forbids the use of the syntax
`<i class="fa fa-check"/> Some text`
to create a labelled icon. But, by this, some fonts are changed.
Desired behavior after PR is merged:
The old syntax can be used.
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
Purpose
=======
Stripe is now a payment acquirer that can be used to manage subscriptions, just like Authorize and Ingenico.
Specification
=============
For Stripe : add "Subscriptions" and "Save Cards" as features on the payment acquirer selection screen
- Added the most used payment option (credit cards) in the world and assigned which payment acquirers can use them.
- Added the form templates for each payment acquirer.
PURPOSE
=======
The field auto_confirm is complicated to understand for common users. Furthermore, on of its options is only useful for authorize module.
SPECIFICATION
=============
Remove the auto_confirm field. The destinies of its options are the following:
- none: Simply disappear.
- authorize: Become capture_manually. It has nothing to do with the auto_confirm field has it's related to the autorize module (And could be extended to other payment acquirers too).
- confirm_so: Remove it. Will be automatic, and we will always validate the sales order and generate the accounting entries on acquirer validation.
- generate_and_pay_invoice: Is linked to the journal_id. The field journal_id is always set and we will use it to validate the sales order and generate the accounting entries on acquirer validation.
Bonus: website_sale: Allow to create/validate invoice automatically on `Mark as Paid`
* add a constraints about authorized state for tx and authorize feature
available on acquirer;
* order acquirers first by publish, then sequence then name;
* add a sequence on some provider data and use a default to have some
popular acquirers first;
* use update instead of write in an onchange;
Laurent Desausoi