Actually the last status is deleted by the fist request who can reach it
So if a request is lost the answer too
With this fix we delete the last response only when we start a new one
closesodoo/odoo#79706
X-original-commit: 63abab836d95df9a45f6f7d038bb18df88f864b4
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened.
With this fix we use the remaining_polls already implemented to get the adyen status with a interval of 3 secondes.
If after 3 tries of 3 seconds each it still fails we can retry manually.
Related to dcb1e2b4823c917f4c547d2cad604187f893948d and f83d1b13a96f8df559918b5905b949009d2ece88
opw:2587625
closesodoo/odoo#76768
X-original-commit: 325b7dde0da6cca27f0d468d1358702d52b8cbaa
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
*: 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)
When there is a connection failure (eg. server restart) while we are
polling adyen for payment status during the payment process, we would
show a connection error and when clicking on retry, we would do a new
payment even if the first one was successful causing a double payment.
After dcb1e2b48, the retry after failure should just continue the
polling as if there was no connection failure, so for example:
- order 1: pay with adyen => connection failure during payment
- order 1: retry => payment successful
But in this particular case:
- order 1: pay with adyen => connection failure during payment
- order 1: close adyen payment line and pay with another payment method
- order 2: pay with adyen => we will receive the response from order 1
With this changeset, we only continue the polling for adyen status if we
are retrying to pay the same order.
opw-2587625
closesodoo/odoo#75640
X-original-commit: f83d1b13a96f8df559918b5905b949009d2ece88
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce the bug:
When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened and then on retry it made second payment
even if the first one was successful.
Fix:
Now after a failure, it will try to poll again the last transaction (with get_latest_adyen_status)
and set the payment as successful or cancelled based on the last response.
opw:2587625
closesodoo/odoo#75053
X-original-commit: dcb1e2b4823c917f4c547d2cad604187f893948d
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Co-authored-by: nle-odoo <nle@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- Dropped adyen.payout model
- Show pos.payment on adyen.transaction
TaskID: 2129218
Closesodoo/odoo#68952
Related: odoo/upgrade#2501
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Improved onboarding / KYC flow
- Display KYC stage for each "document" (identity, bank account,
shareholder, etc.)
- Only update to the API what's been updated by the user to prevent
undergoing another full round of data verification
- Show new pricing
- Support refund of adyen.transaction
- Simplify payouts (let Adyen automatically handle them)
- They are now automatically handled by Adyen and not manually
triggered by a cron
- "Balance" dashboard
- Show the balance per currency
- List of payouts and their status
- Handle account/transaction notifications
- Show split of fees
- Details on payment method (card country, card type, etc.) used
- Display details from the linked payment.transaction
- Verify proxy signature for notifications
- Notifications are now signed and authenticity verified
TaskID: 2129218
Closesodoo/odoo#68952
Co-authored-by: Antoine Prieels <anp@odoo.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Show a nice error message when starting negative transactions on Adyen
terminals.
opw-2368978
closesodoo/odoo#60985
X-original-commit: 4dc790629e49c6e78a009fde3a22915944bb5583
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
- The Adyen sync cron didn't call the function to sync terminals
- Do not specify the merchantAccount when creating a store, the proxy
will add it itself.
closesodoo/odoo#59868
X-original-commit: d5b456a1f75320c8fdf1e989afad91fc74ec9ef3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The goal is to add a nice payment solution to our users.
- Why Adyen?
- Worldwide
- Manages local payment solutions
- Easy onboarding
- For both PoS and eCommerce
- Why Adyen for Platforms?
- The onboarding will be done directly from the customer's DB.
- It's quite complicated for SMEs to get a partnership with Adyen as
they have high requirements for transaction volume. By registering
Odoo as a Platform with Adyen Marketpay, we allow our users to
register as sub-merchants under a common account, removing this
constraint.
As all users are grouped under a common account, all requests need to
provide the same API key. As this key cannot be shared, all requests to
the Adyen API will need to be proxied. A new proxy will be created on
`paymentproxy.odoo.com`.
To initiate a payment, 3 values are required:
- `account_holder_code`: This code is provided by Adyen and is used to
identify the sub-merchant under the common account.
- `adyen_uuid`: This ID is used internally to identify the user.
- `proxy_token`: This token is generated by the proxy during the
account creation and is used to sign all requests.
The DB of the customer is the only host who has all the information
required to modify the sub-merchant info or initiate a payment. If
this information leak, the `proxy_token` can be reset on the proxy to
revoke all access to the API.
Before accessing the form to create an account, users will be
redirected to www.odoo.com where they will be asked to log in. This
ensures that we have contact information for this sub-merchant.
TaskID: 2129218
Revert commit e6372c3, the concurrent updates were solved by the change
in the order of the lines, not by the fact that functions were defined
as api.model
As long as the payment is not validated, the cashier can add products
to the order, even if the payment has been completed. The amount
authorized can be adjusted if the payment interface implements the
canBeAdjusted method.
closesodoo/odoo#56656
Taskid: 2117032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The amount is authorized when the customer scans its card, then the
customer writes the tip on the receipt and the total amount is captured
when the waiter manually inputs the tip, either right after or at the
end of the day.
closesodoo/odoo#56148
Taskid: 2321771
Related: odoo/upgrade#1661
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Disqualify the constraint in the adyen identifier if it is empty because
it is not needed in other payment methods that are configured with other
payment terminal.
closesodoo/odoo#36702
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
For now when you are using payment terminals in the point of sale, you
have different way to configure payment temrminals, for the IOT, you
have to select the payment terminal in the pos config, and for adyen and
ventiv you have to configure them in the payment method.
So we've modified it to always configure payment terminal on payment
mehthod, and not on the pos config anymore, with iot you'll be able to
select the specific device you want to use, even if it is not on the iot
box set on the pos config.
closesodoo/odoo#35665
Task-id: 2042382
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Every time we check the status of a request (every 3 seconds) we also
launch another request to check the status of the terminal. This way
we can notify the user if the terminal is no longer reachable.
Even though we call Adyen's async endpoint for this it can still take
a while to complete (>2 seconds). Before this change the
pos_payment_table would be locked for this entire duration. This means
it's now likely that during this time Adyen calls us back to say the
transaction is finished. It needs to write on the payment method which
causes the concurrent update error.
Odoo's automatic retry mechanism would usually handle this fine but
it's not pretty solution.
Instead let's convert the methods that do the async call to @api.model
functions and pass in all the data they need. This solves the problem
because now we won't need to lock pos_payment_method for the duration
of the request.
This allows Adyen's POS terminals to be used in the POS. The
architecture is as follows:
Odoo <--> Adyen server <--> Adyen payment terminal
It means we don't have to communicate directly with the
terminal. Instead we send HTTP requests to Adyen's API and they take
care of the rest. Therefore this integration doesn't require an
IOTBox.
Unfortunately this module is more complicated than it needed to be due
to Adyen's API not supporting CORS. Because of this we can't directly
call their API from JS. Instead we need to proxy requests through the
Odoo backend. This complicates things further because this means we
can't use their synchronous API. With this API an HTTP request remains
open for the entire duration of a transaction. We can't afford to
block an HTTP worker this long. So this implements their asynchronous
API which calls us back when a transaction completes.
In addition to the regular sale requests we also poll the status of
the terminal using DiagnosisRequests while transactions are in
progress. This is to handle cases where a payment terminal loses
connection after a payment transaction is initiated. It also handles
cases where a terminal was recently disconnected (<1 min). In this
last case Adyen will process the payment request as usual, without
notifying us the terminal is offline. It's important to notify the POS
user to check the terminal, otherwise he'll have no idea something is
wrong. We store the DiagnosisResponse's unique ID and every time the
POS requests a status update we launch a new DiagnosisRequest. When we
no longer receive DiagnosisResponse ID updates we can notify the user
of this in the POS.
To test this locally use something like ngrok so Adyen can call you
back.
API docs: https://docs.adyen.com/point-of-salehttps://www.odoo.com/web#id=1981799&model=project.task&view_type=form&menu_id=
Martin Trigaux