The logs for payments contain the transaction reference whenever possible.
Before logs for transactions contained the reference or the id of the
transaction in an inconsitent way. No transactions are identified by
reference whenever possible.
The logs for payments for the same function on different acquirers should
have the same format. Same flow step for different acquirers had
information passed in different formats. Now at each step of a transaction
flow log messages have the same format regardless of the acquirer.
Overall the payment logs should have an uniform format. Hopefully
understanding log messages related to transactions should be easier, as
now log format is independent of the acquirer and transaction are easily
identified by reference.
Task - 2545450
closesodoo/odoo#79547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.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>
Fix two issues:
The search of suitable payment token was searching on the journal_id
field of the payment acquirer that is no longer stored.
Change it to now search on the acquirer_id directly, since we have
this information.
The _inverse_journal_id method on payment acquirers would create
new payment line with the manual payment method when no provider
are given to an acquirer, or no payment method is existing for
a given provider. This would cause issues with the creation of
multiple line with the same name on a same journal, which would
trigger the constrains blocking that.
closesodoo/odoo#74990
X-original-commit: a3a2fcb0b299fafbf359ec9015da5c85cdb57b3a
Related: odoo/enterprise#20193
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, the payment function `_get_validation_amount` was
overridden by Stripe to specify a validation amount of one currency unit
while that amount was in fact never passed to Stripe in the validation
flow. The amount stored on the transaction was therefore incorrect.
This commits removes the override to let the default amount of 0 being
set on validation transactions.
task-2612977
closesodoo/odoo#74543
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Prior to this commit, not all operations of the Stripe webhook were
encapsulated in a try/except clause. If a `ValidationError` was raised
outside of that clause, it was returned as-is to Stripe.
This commit encapsulates the whole webhook event processing with a
try/except clause to make sure that only an empty string is returned to
Stripe, hence properly acknowledging events.
task-2612977
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>
Issue:
Payouts reference on Stripe are display as:
`SUB123 - ODOO_PARTNER_456789`.
Cause:
When making a Stripe request to create new customer, the description
is formated as : `ODOO_PARTNER_456789` .
Solution:
Replace customer description format as :
`Partner: Mitchel Admin (id:456789)` .
Inspired by: https://github.com/odoo/odoo/commit/3bc1e0175d85a70806999109e928c234e8cc2ca4
opw-2593621
closesodoo/odoo#74109
X-original-commit: 07033a07ca49923a1c5095c371302fb894363c07
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
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>
- The acquirer reference was never saved.
- Transactions with operation 'offline' were not processed.
- If Stripe rejected an offline payment, an exception would be raised.
This lead to Subscriptions assuming that the processing itself failed
and prevented the transaction to be processed. Instead, the exception
is now caught and the transaction's state set to 'error'.
task-2494916
closesodoo/odoo#71602
X-original-commit: e93b3b3c5b9bc86768a5d26ed456ef11cfb40734
Related: odoo/enterprise#18680
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
When the payment form is displayed, Stripe.js library isn't loaded, thus preventing the customer to pay online.
When the refactor of assets was done, the link to the Stripe library was moved to __manifest__.py.
As the link does not end with '.js', the file wasn't loaded anymore.
See PR #60632closesodoo/odoo#69849
X-original-commit: 8535b090a36fe6472c4b3d8211f3be39c7f1c58a
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Valentin Chevalier <chevalierv@users.noreply.github.com>
This PR changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
closesodoo/odoo#60632
Task: 2352566
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@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>
Special character in reference (eg. '#' character in invoice sequence)
might cause error after payment not showing it was successful.
With this changeset, when a payment reference is used inside an url, we
quote it.
opw-2479658
closesodoo/odoo#68585
X-original-commit: 47645c2f170d5a7c09ae80d4e0de6c3a821f7b36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commits drops the direct payment flow supported by the SetupIntent
API in favor of the payment with redirection flow, supported by the
Checkout API only.
See the merge commit for more details.
task-2333040
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Steps to reproduce the bug:
- Let's make a bancontact payment with Stripe on mobile from the web shop
- Stripe redirects you to Odoo
- Your phone asks on which browser you wanted to redirected to Odoo
- Choose one
Bug:
An internal error was raised.
When you clicked on a browser (the same you were using or a new one, whatever)
Odoo will resend a request to Stripe. But this request will have wrong data in it.
Stripe will answer with:
Stripe: entering form_feedback with post data {'error': {'code': 'resource_missing',
'doc_url': 'https://stripe.com/docs/error-codes/resource-missing',
'message': "No such payment_intent: 'py_1I6c4UKhH8RhRq18TJs2CP0z'",
'param': 'intent',
'type': 'invalid_request_error'},
'reference': 'S00002-1'}
opw:2422031
closesodoo/odoo#64385
X-original-commit: a42075c9f913f4a20b28f97f0f6786f5a7b2968a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The `name` field is not required on the `payment.icon` model. Therefore,
in case the payment icon name is not set, a traceback is raised due to a
`False.lower()` statement.
opw-2409755
closesodoo/odoo#62646
X-original-commit: 54434a4fdd71b1e344255fb6f3e42d731ba91f3b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Same change in several areas where translations existed:
- website editor notification popup
- elearning share popup
- forum remediation filter popup
- event registration attendees popup
- portal rating popup
- stripe payment error popup
And many other locations where there were no translations yet
"×" has been replaced by its UTF8 character.
Also introduced aria-label where missing.
Before this commit the close icon was included in translated resources.
For example, in Spanish the "×" had been turned into "&veces;"
thus not rendering an icon anymore
After this commit the close icon is not a translated text anymore and
remains an icon across all languages
https://github.com/odoo/odoo/pull/60186
task-2312878
closesodoo/odoo#62250
X-original-commit: 9896af94ebc887d98ccf44e6568ef7eeb5a27172
Related: odoo/enterprise#14937
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
Allow configuring a webhook in Stripe to send s2s notifications to Odoo
when a Checkout payment is completed. Note that SetupIntent and
PaymentIntent events are not listened to, since they are handled 'live'
with the customer actively present; the main use case for Stripe
webhooks is a Checkout session that gets interrupted before the customer
is redirected to Odoo (e.g. network loss, browser crash, closing the
tab, etc.)
The webhook should be configured to send its events to
<base_url>/payment/stripe/webhook and should only subscribe to
checkout.session.completed events to avoid spamming the Odoo server with
useless notifications.
closesodoo/odoo#52754
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
Issue
- Install eCommerce, Stripe
- Setup stripe for testing
- Order something
- Open stripe payment interface (not with odoo)
- Go back with the stripe interface button
Order Cancelled
- Go back with browser back button
- Enter your data
Can pay but order still cancelled so
you paid for nothing
Cause
I fixed a linked error in
b8b9a04ff5b5b2ba40b26632
but I didn't mind that we should cancel
the stripe payment intent too
Solution
Cancel the stripe payment intent so that
filling the stripe form by following
those step will returns an error from
stripe
OPW-2282946
closesodoo/odoo#53819
X-original-commit: 5acb2a649a2f2490725283c7f4cff5a5183d8ed0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
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.
- Go to Website > Configuration > eCommerce > Payment Acquirers
- Activate Stripe
- Configure Stripe
- Go to Sales
- Create a quotation
- Send quotation by email
- Click on "Customer Preview" smart button
- On Website, click on "Sign & Pay" or "Pay Now" if already signed
- Sign it and confirm on "Accept & Sign"
- On payment wizard, select "Credit Card (powered by Stripe)"
- Validate with "Pay & Confirm" button
An error message appears.
opw-2262990
closesodoo/odoo#51815
X-original-commit: 3c5117eaac96604a3306c90480d106e0e36fed2f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Revision 29b3b67a16 introduced payment with iDeal but accidentaly
introduced an issue where some payments did not go through (in fact,
some cards could not be saved, preventing the payment to occur).
This fix prevents this issue from happening by clearly differentiating
between returns from the Checkout process and from the Elements process;
in the case of a Checkout flow, the 'card' key is always present in the
data dict but can be equal to None if a non-card payment method was used
(e.g. iDeal) while in the case of an Elements (payment from Odoo) flow,
the 'data' key is never present and the card information has to be
downloaded using a get request to the Stripe API.
opw-2253269
closesodoo/odoo#51269
X-original-commit: f0ba15cda070e968699cf77ac0ba58234dbdaf51
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The `payment` module introduces a certain amount of payment acquirers,
each one corresponding to a `payment_` module.
When a `payment_` module is installed, this data is updated so that
payments done with the corresponding acquirer change in behaviour using
the provider installed by the `payment_` module.
When a `payment_` module is uninstalled, this data should be reset to
default, more especifically the `view_template_id` and the `provider`
fields of `payment.acquirer`.
This was not possible before this commit, and more importantly it would
make the uninstallation of such `payment_` module impossible as the
`view_template_id` is a required m2o ondelete='set null', which will
make the registry crash. Even if the former wasn't a problem, the
provider field would remain set to a non-existing selection option,
which would make the registry crash (eventually, when checking a record
with such a selection option).
With this commit, we reset these fields to their default value upon
module uninstall.
In 13, the issue with `view_template_id` should be fixed, as required
m2o that are ondelete='set null' are no longer possible. As for the
provider Selection field, a fix should arrive in master soon.
opw-2225333
closesodoo/odoo#48916
X-original-commit: 4f0c1c1bfd71dd1ff6793d0a91b49984c54d1351
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Install eCommerce
- Set Stripe up (API keys)
- Go on Shop
- Add a product > Checkout
- Pay with stripe
- Go back when arriving on Stripe payment page
(top left link)
Empty error box
Cause
This behavior is not handled by payment_stripe
Solution
Cancel transaction when going back.
It will display a message "transaction cancelled"
OPW-2195385
closesodoo/odoo#47113
X-original-commit: b8b9a04ff5b5b2ba40b26632e2395b7cdb7ea300
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
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>
Issue
- Install eCommerce
- Add Stripe
- Pay with invalid cart
Traceback
Cause
When I improved stripe error, I didn't checked if
an error could have no event
Solution
Check if the error has an event
OPW-2186385
closesodoo/odoo#44414
X-original-commit: 772c02743b5e6610a75e65e408c956eb6057a47d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
In some cases, Stripe will return the result of a transaction with
a faulty HTTP Status (e.g. 4XX statuses) - not because the request
was malformed, but because the payment failed. It is a bit unfortunate
that Stripe would not differentiate between payment status and request
validity, but that's the state of things.
This commit ensures that such a response will be logged correctly, by
making the call to `raise_for_status` conditionnal on the response object's
status code and internal structure, forwarding the response's json to the
validation flow if the status is in the 4XX range and a `code` key is
found in the response, as described in https://stripe.com/docs/error-codes
While testing this fix, it became apparent that some error message
processing in the frontend was not correctly handled as well - instead
of purely rejecting the promise, a failed payment should still send its
payload to the backend, to allow the server to put the transaction in
the correct state according to the response.
Reproduce the issue
- Install eCommerce
- Activate stripe, use testing credentials and select
Configuration > Payment Flow > Payment from Odoo
- Create a contact that has a trailing whitespace at the beginning
of the email
- Grant him portal access, and a password
- Open your browser devtools
- Login to the web shop with this portal user and buy an item using
stripe
1. Error Dialog: Server Error (HTTP 500)
2. The exception received by the front-end is not clear
3. When the 500 error is fixed, we still have a error dialog
=> bad UX
Cause
1. The raise was removed but we need to keep it because
it allows the true error to be raised (bad request)
2. The "invalid email address: x" is lost when we raise the
exception
3. In V13, all catch & guardedCatch open a error dialog if we
don't set preventDefaulted to true on the error's event
This commit changes restore the raise, change the error message and
disable the error dialog for this case.
OPW-2126196
closesodoo/odoo#41087
X-original-commit: b8d013285ba54c8d3ab4a3857604dfca3e479b39
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
In case the Stripe API call fails, an Internal Server Error page is
displayed to the user, which is not user friendly.
opw-2126196
closesodoo/odoo#40678
X-original-commit: 95a452f6d928de2e8532027893a353167ffdd389
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit, when try to make payment with
empty card details, it will raise error dialog.
after this commit, error will be append to acquirer
form
task - 2089999
closesodoo/odoo#39729
X-original-commit: 01b143b971a85d6da673df6c536917ad4754b83a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Makes it easier for users to match Odoo payments with information
from the Stripe dashboard.
closesodoo/odoo#39465
X-original-commit: 0a55cb29542da20bb9d0543e2b30d125124f861b
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Adapt the API changes in Stripe. Use correct test data existing in
Stripe dashboard for our test account.
closesodoo/odoo#39455
X-original-commit: 4dab64285ab410f239935437b273a0c97951e902
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Horacio Tellez