Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Users can now ask for a refund from Odoo for their transactions done
through Authorize.net. A refund will be triggered from Odoo when
necessary.
Only full refunds are possible.
Note that unsettled transactions will be voided as they cannot be
refunded.
Task - 2678757
closesodoo/odoo#92279
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The multi-company common of payment was only used in a single specific
test class of the same module. Since we don't aim to test multi-company
flows in specific payment_ modules, we might as well remove the common
and move the setup content in the only class using this common.
Task - 2848326
Part-of: odoo/odoo#90716
During the payment pocalypse, new tests common were introduced. Those
commons were split into different classes to be as modular as possible
but we noticed during the following months (/year) that they weren't so
easy to understand and use.
Therefore, this commit aims to simplify those commons by removing the
core PaymentTestUtils common, integrating it in the base PaymentCommon,
and making the HttpCommon depend on the core PaymentCommon, instead of
using only the utils.
This doesn't require much changes in the tests since they all used
either the PaymentCommon or both PaymentCommon and PaymentHttpCommon.
Task - 2848326
Part-of: odoo/odoo#90716
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>
Before this commit, users may saw the capture and void buttons but
couldn't use them.
As capture or void actions need to access acquirer-related fields,
these actions are now sudoed to allow any users that see the button
to use it.
The access rules and rights are also checked before executing the action
to avoid abusive RPC calls.
task-2785144
closesodoo/odoo#91923
X-original-commit: 2e351d6ff9b7f72b486e83c827ff6e15a05c3331
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
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>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
When a 'manual capture' is set for Authorize.net and a client
make a payment in several partial payments the user can capture
all the authorized transactions without crashing now.
Task - 2676914
closesodoo/odoo#90212
X-original-commit: 68b354f7353e3b5fd1faaad1b762c3c73a286f0f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Current behavior:
Public user have access to payment method that require tokenization wich leads to error when they use it.
We should not show those payment methos to the public users (e.g We shouldn't show sepa direct debit because this method uses tokenization)
Steps to reproduce:
- Activate SEPA Direct Debit in the payment acquierers
- Select Bank as payment journal
- In the bank payment journal create an account number (e.g BE71096123456769), and select a Bank (e.g BNP)
- Create a new customer (type : company, country : spain, and an email)
- Create a quotation with this new customer
- Click on the "action" icon and click on generate payment link
- Open the link in an incognito window (to make sure you'r not connected in Odoo)
- Try to use the sepa direct debit
- An access error appears because public user do not have access to payment.token.
opw-2754505
closesodoo/odoo#86415
X-original-commit: 2a084c4810c6d1af82901882d1588c8449ebdc78
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit, the /payment/pay page would not filter out acquirers
configured to allow tokenization when it was although required for the
payment. For example, for sales order with a subscription product (which
requires tokenization), acquirers that don't allow tokenization would be
shown to the customer if they pay from the /payment/pay page, but not if
they pay from the portal view of the SO.
This commit makes sure the sales order id is correctly propagated to the
Subscription app which then flags the payment as requiring tokenization.
closesodoo/odoo#86202
X-original-commit: 9ab7b2447f2ece46f1a25335ab76f06323f03d22
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For payment_buckaroo and payment_sips (at least) running with a
non-standard port is an issue to the `test_redirect_form_value` tests:
while the form and test will use respectively the base_url and the
configuration port, both check a response signature which is
predicated upon a base url of `http://127.0.0.1:8069`.
This means the test does not pass when run with a different port, and
may not pass if the database was installed with a different port
either (because this may have caused the `web.base_url` to be set to
the installation port).
The other payment modules don't seem to have such signature
verification and thus apparently don't mind running with non-default
port.
Update in 15.2: `test_webhook_notification_confirms_transaction` also
broke but differently, because the payment utils would fetch (and use)
the `web.base.url` they get confused if a db is installed using one
port then the tests are run using an other (or something along those
lines), despite `HttpCase` trying to set the `web.base.url` (could be
an ordering thing).
Anyway a working solution seems to be to *remove* the bespoke code
from `PaymentTestUtils` and fix `HttpCase.base_url()` so it uses the
right port (apparently that'd never been fixed). This does require
adapting the patch being forward-ported as `base_url` is now a
callable, not an attribute.
Also re-remove the attractive nuisance of the odoo.tests.common.PORT
constant which does not work: it is evaluated before the configuration
has been loaded and is thus always set to the default (8069).
closesodoo/odoo#86068
X-original-commit: c28c99f7399da91e1a6176d6f97d4fc947013cae
Signed-off-by: Xavier Morel (xmo) <xmo@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 modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Whenever making a refund for a transaction with a saved token
the token will appear also on the refund transaction.
It is useful to keep track of which token was used in each
transaction, this remains true for refunds.
The token will also appear on the payments.
Task - 2694760
closesodoo/odoo#85484
X-original-commit: 351812a81ec29fe96bf3766c45ea3b51f4055066
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
We split the test in three to allow easier debugging at no cost in line
of codes and by extracting a part that could be used for future tests.
task-2659750
closesodoo/odoo#85162
X-original-commit: 8502d4ec895f2d4a2ddb1b305a9f6f119da750fa
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@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>
Current behavior :
In a multi-company environnement if you generate a payment link and access it from incognito page the company was always the logo of the first company.
Steps to reproduce :
- Get in a multicompany environnement
- Create a invoice in company B
- Generate the payment link in the action menu
- Access the link in incognito mode
- The company logo is always the logo from company A
opw-2756438
closesodoo/odoo#85000
X-original-commit: 0e2e79d055e8565e2913b30477fcfdb71e99bdae
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@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>
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
Adding a test to verify if `send_payment_request` is used once and
only once, and under the right conditions.
In the utils, we change the direct use of `opener` in
portal_transaction for a softer use of `url_open` which manage the
url and then call the `opener` for a same end result.
task-2659750
closesodoo/odoo#84582
X-original-commit: c9371a2ec8dfbd7e55b1b6595e2a76d76ee36e12
Related: odoo/enterprise#24338
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was impossible to make a payment if the
transaction reference exclusively contained digits. This is because the
reference is extracted from the data-* attribute of the <form/> element
of the payment form and wrongly cast into an integer by jQuery before
being passed to the server. Indeed, as of jQuery 1.4.3, HTML5's
data-* attributes are automatically pulled into a jQuery's data object.
To reproduce the issue, remove the prefix from the sequence of the sales
orders and attempt to pay a quotation from a payment link.
This commit forces the reference to be cast into a string as it is the
variable type that the server expects, and it crashes if the reference
is an integer.
opw-2732448
closesodoo/odoo#83753
X-original-commit: 57d9997fa59c82e03c46b149daece5ce32395c5c
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
Wolfgang Taferner