Before this commit:
In POS online payment the usually the user is either the
logged in user/public user which ends up raising error
`The phone number is invalid` even when the customer is selected
After this commit:
Razorpay doesn't raise the error instead now we don't create
customer when it is not a tokenize request
task-3786679
closesodoo/odoo#157533
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Each payment acquirer has its own implementation specificities: some
implement a 'payment with redirection' flow and others a 'direct payment
flow'; sometimes the 'payment with redirection' flow is even implemented
as a 'direct payment' flow through an iframe; one payment acquirer could
support webhooks while another does not and relies on another mechanism
to fetch payment status updates...
It can be tricky to guess where to look in the code to determine how a
payment acquirer is implemented.
On top of that, the online payments ecosystem evolves at a fast pace due
to competition, buyouts, and legislation enforcement. Acquirers are thus
frequently migrated to new APIs that might differ in implementation from
the previous API.
To help figure out the *which*, *why*, *how*, and *when* of payment API
implementations, a README.md file is added to the main directory of all
payment acquirer modules. They can be browsed in human-readable format
on GitHub.
task-2374916
closesodoo/odoo#156084
X-original-commit: 4c19f26df3d39394cce2f183d6df15c5b89c7d27
Related: odoo/enterprise#57921
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Steps:
- Install subscription and razorpay app.
- Configure razorpay provider with tokenizable
razorpay account.
- Enable allow tokenize field.
- create subscription with more then 100k and
less then 500k amount.
- Try to pay that subscription with razorpay.
Issue:
- Throwing limit exceed warning even though amount
is less then 500k which can create token and paid
normally.
Cause:
- We forgot to check minimum of method max amount and
amount * 5 to send proper mandate max amount while
creating token and because of that paying more then
100k via subscription raise error even to it should
processed normally.
Fix:
- Check minimum of `method max amount` and `amount * 5`
to send proper mandate max amount so it'll not raise
error while paying amount in between 100k to 500k.
closesodoo/odoo#150410
Related: odoo/enterprise#55009
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, the `TODO: remove in master` is treated as a string, but it
is actually a comment. Therefore, I converted it from a string to a comment.
closesodoo/odoo#149883
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit razorpay provider handle both authorized
and done event for transaction even though razorpay return
both authorized and done event at same time and there is no
need to handle authorize event if capture manual is disabled
on razorpay and because if handling both events at same time
it causing serialization issue and it might cause serious
issue if other operation are being executed on same time.
This commit handle authorized event only when capture manuallly
option is enabled on razorpay so it will not try to write on
operation at same time and avoid concurrency issues.
task-3652228
closesodoo/odoo#147534
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When user enables or tests payment provider it will automatically
enable most used payment method in that provider.
closesodoo/odoo#140907
Signed-off-by: anko-odoo <anko@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
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>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
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>
Currently, when the partner phone has space, Razorpay throws an invalid phone exception error.
In this commit we sanitize the partner phone.
Case 1:
If partner phone is empty then validation error will be arrived. 'Phone number is required'.
Case 2:
If partner phone is not sanitized then validation error will be arrived. 'Incorrect phone number'.
EX: (+91 96385 44240) -> (+919638544240)
task-3113199
closesodoo/odoo#108969
X-original-commit: 38af5ee6a4feba802d50305fab8c001494f4e538
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
auto_install is Falsy by default
author is Odoo SA by default
summary & description are empty strings by default
application is False by default
test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content.
closesodoo/odoo#106686
Related: odoo/enterprise#34462
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We decided to make this list as feature and not application.
It allows any user in mode OneAppFree to use them without become an
Extra App.
List of apps impacted:
blog
forum
all payments acquirer
task-3062641
closesodoo/odoo#106487
X-original-commit: 8b1928b3ef0e098b193ac74084344eba5beac4db
Related: odoo/enterprise#34368
Signed-off-by: Thibault Francois <tfr@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>
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 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>
*: 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>
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>
Odoo Translation Bot