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 validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
When computing the inverse of `journal_id` on a batch of
`payment.acquirer`, a payment method is created if there isn't any.
As this process can only be done for one acquirer at a time, we must
populate the data accordingly.
closesodoo/odoo#74668
X-original-commit: 493b1ca54d6831f044726b2d8942e7e7f7ce3098
Signed-off-by: William André (wan) <wan@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>
Before this commit, it was not possible for an acquirer to support
tokenization while not supporting validation because the acquirer would
be thought to be compatible with either flow based on the
`support_tokenization` field. This was a false assumption because some
acquirers, such as Ogone, can offer to tokenize a payment method in
payment with redirection flow while not allowing tokenizing a payment
method for future usage, without payment.
Note that this was not an issue for acquirers supporting the direct
payment flow because they could either support validation natively, or
seamlessly charge a small amount and refund it immediately to tokenize a
payment method.
This commit makes it possible for a module implementing the validation
operation to filter acquirers based on whether they support it,
regardless of their support for tokenization.
task-2494916
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Need to check and mark legit uses of HTML as Markup. Also fix some
title formattings which are not great (mostly around translations) and
de-escape titles which don't need to be escaped anymore.
Add HTML fields support to kanban view (currently bespoke but maybe it
should be done via `format`), and remove t-raw for HTML fields there.
Also just strip some t-raws which were completely unnecessary to start with
There is an issue when computing the suitable payment token ids making it impossible to
open a payment for a user without access to payment acquirers.
Also, the default computation of payment token was wrong and would never set it
correctly.
The compute for the method lines in payment would not filter unavailable acquirers
line and thus select them by default if they were first in line.
Also fix an issue with the ordering of payment method lines
X-original-commit: 73410a0fd76a70e1730883d35b79fc603741b59c
The journal needs to access the payment acquirers to determine with payment method is still available.
Since the acquirers can't be accessed only for admin users, an accountant doesn't any right to read them, and then, an access error was raised when opening the journal form view.
Also, the 'payment.acquirer' was accessed from the 'account' module instead of being overridden in 'payment'.
closesodoo/odoo#73761
X-original-commit: 7b4580c3756657c902eceb9840984dde76429dcd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Change dependencies of a few computed fields in order
to avoid triggering them wrongly when migrating.
Also add a company check on the constrains blocking
deletion of payment method lines linked to an active
acquirer.
closesodoo/odoo#73731
X-original-commit: e94b4f09a4c5664360594bee6475cb2ef756be47
Related: odoo/enterprise#19663
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Small UI improvements for clarity/continuity:
1. In the "Sales' onboarding wizard > payment configuration >
documentatlion link", font roboto is now used.
2. In the sales order, the error message when 'there is nothing
to invoice' now also explains also what the user has to do to invoice
"Prepaid" services.
3. In the "Payment confirmation" section of the payment portal,
'Reference', 'From' & 'Amount' fields don't look like editable
fields anymore.
4. In the payment forms, tokens created with the Test acquirer
are now identified with a "Test Token" badge in place of the
verified token checkmark.
task-2505913
closesodoo/odoo#70076
Related: odoo/enterprise#18036
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
With commit 139dd9d, the Hosted Payment Page API of Ogone was entirely
replaced by the FlexCheckout API. This new API allows customers to
tokenize a payment method for a later use without the need of making a
purchase. However, it proved itself to be less convenient for regular
purchases as it offers less payment options than the HPP, and payments
are no longer cardholder-initiated transactions but merchant-initiated
transactions which have a higher chance of triggering an authentication
check. Furthermore, the payment flow itself is more complicated than
before.
This commit brings back the Hosted Payment Page API to work in parallel
with the FlexCheckout API and the other APIs that were left untouched.
It will be exclusively used for making online payments with a new card.
The validation flow is managed by the FlexCheckout API while the
DirectLink API manages the payment by token and offline payment flows.
task-2494916
closesodoo/odoo#72991
X-original-commit: 4fa7b772c71979f61eb098ff8d005deba834527c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
While HttpCase did set `web.base.url` before starting a browser, in
the non-browser test cases (or cases which would mix browser and
non-browser) it would not do so.
This is an issue when installing the database with one http-port and
running tests with an other e.g. after duplicating the database (or
even not duplicating it) in order to run multiple test instances
concurrently, which requires using different http ports.
Tests would then see the base url generated during installation,
embedding the port used at installation, and would break weirdly (at
best exploding due to not finding any server to bind to, and at worst
making request on the wrong instance entirely). Simply updating the
base url during setup seems to fix most of the tests.
Notes:
* Some tests (e.g. survey) don't flush() their create/update before
calling `start_tour` or `browser_js`, the implicit flush because of
the ICP handled the issue. Perform an explicit flush of base
(similar to `url_open`) to ensure they keep working correctly.
* `url_join` should handle absolute URIs correctly, it does imply
slightly different semantics in case the `base_url` has a non-empty
path, but that seems like a very limited risk (and possibly
convenient to boot).
* `payment` needed a fix because the vagaries of the MRO led to the
extra parameter internally used by the thing to be passed to
`HttpCase`'s `setUpClass`, which would not expect it.
closesodoo/odoo#72645
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since the payment post-processing cron runs every ten minutes, it is
important that it ignores the transactions that were updated in the same
last ten minutes. This is necessary because customers can only see the
payment confirmation message for transactions that were not already
post-processed.
Commit 573ed74 mistakenly changed the post-processing delay from ten
minutes to one minute. This commit changes it back to 10 minutes.
task-2494916
closesodoo/odoo#72742
X-original-commit: 502a13b87971b0bf36493770dd3bcb4f9d9b7c2a
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Valentin Chevalier <chevalierv@users.noreply.github.com>
The "Installed" filter domain in the search view payment.acquirer was wrong,
showing only uninstalled acquirers.
Task Id - 2494916
closesodoo/odoo#72487
X-original-commit: 9082e36a9b150ded361f26beff5525b31738e0e0
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before commit 139dd9d, only validation transactions made with a validity
check (transfer of a small amount with immediate refund) led to the
creation of an `account.payment` record for the reconciliation. As that
amount was never perceived, there was in fact nothing to reconcile.
With commit 139dd9d, it is possible to make $0-validations (the validity
check is handled by the provider). As this feature now sheds light on
the flawed behavior described above, it has been decided to entirely
stop creating `account.payment` records for validation transactions.
This commit thus prevents the post-processing of validation transactions
from preparing their reconciliation.
task-2494916
closesodoo/odoo#72137
X-original-commit: f460d7a5a995cd7b934d32f82b50aede43efbace
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
If a payment request is made from a cron (e.g., Subscriptions' cron for
recurring payments), the worker is not bound to an HTTP request and
therefore the value of `request.httprequest.remote_addr` is an instance
of the 'LocalProxy' object, which is not serializable.
If we're in this scenario, don't send the customer IP address.
task-2494916
closesodoo/odoo#71717
X-original-commit: e85464ad2281f25cbaf7ded0c1e5d7659a322696
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Co-authored-by: Toufik Ben Jaa <tbe@odoo.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>
- 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>
Actually, salesmen have to add manually the acquirer_id to the link, and it isn't user-friendly. The dropdown will show the possibility to add the acquirer_id.
Task #2504225closesodoo/odoo#69334
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
Currently, clicking on the "upgrade" button from Apps in community
opens the corresponding page in the same tab. As a consequence, the
user completely leaves his database and it can quickly become tedious
to get back to it.
so in this commit, clicking on the 'upgrade' button should open the
corresponding webpage in a new tab
closesodoo/odoo#70636
Taskid: 2513785
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Issue
Use Safari (or equivalent) browser
- Install e-commerce
- Go to Website -> Configuration -> Payment Acquirers
- Activate Ingenico in test mode
(write aaa in required fields)
- Go to shop, and add product to card
- Go to checkout
- Select Ingenico payment mode
- Click on Pay button
- When on the ingenico page, press back
The page is blocked and the button is disabled.
Cause
When clicking on Pay button, the page is locked and
the button is disabled.
With Chrome, when coming back to previous page,
this one is regenerated and therefore adapt the button.
In Safari, it is not the case.
Solution
On `pageshow` event, if event have `persisted` attribute set to
to true, meaning using cache, then reload page.
Fixes https://github.com/odoo/odoo/issues/69453
opw-2510281
closesodoo/odoo#70906
X-original-commit: c89224940bcc59aab4bddefa95b2b0ef7713e02f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@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>
The *_msg fields are HTML fields so there's no reason to do anything.
A few of the values are a bit more debatable though:
* Thanks_msg seems pretty much never used?
* The `message` value comes from `state_message`, looking at how
that's set it doesn't seem like there's any reason for it to ever
contain markup?
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.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>
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>
Payments made on eCommerce via a payment acquirer (i.e. Stripe) generate an
"account.payment" record where connected user's "child" partner is used for
partner_id of the payment, instead of commercial partner, as it is done for
payments registered on invoices.
For consistency, commercial partner should also be used for these payments.
opw-2457390
closesodoo/odoo#68065
X-original-commit: b738068be53621b23d9f19befdfdef50534ef434
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Steps:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
The field partner_id on model payment.transaction is not required
So in some cases if the field partner_id was not in the values
It raised a traceback.
opw:2467971
closesodoo/odoo#67018
X-original-commit: 41b0d78c861a94630be28a16a13f2bae1b629777
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps:
- Go to Settings > Users & Companies > Companies
- Create a new company (1)
- Install a payment acquirer and Website
- Go to Website > Configuration > Settings:
- Select "My Website 2"
- Assign it to company (1)
- Add a custom domain
- Save
- Switch to company (1)
- Go to Invoicing
- Create a new Invoice:
- Add a product line
- Post it
- Click Action > Generate a Payment Link
Bug:
The base domain is used instead of the domain of the website linked to
the invoicing company.
Explanation:
The app only uses the URL on which the user has logged in to generate a
payment link. If the user has multiple companies, this can confuse
customers if they land on another domain than the one they are used to.
This commit makes the app use the domain of the website of the record
linked to the payment if it has one.
opw:2440251
closesodoo/odoo#65938
X-original-commit: 700dba53843e71f5f34c86305cc658d9273914aa
Signed-off-by: backspac <backspac@users.noreply.github.com>
Purpose of the task, is to prevent users from inadvertently
creation/opening countries from country_id fields.
Countries should be managed from their dedicated menu item.
so in this commit, we have set both no_open and no_create to True
so user should not update and create a country from the many2X fields.
closesodoo/odoo#63773
Taskid: 2241677
Related: odoo/enterprise#15464
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If a user has the portal access, when going to his documents, if one of
them belongs to an archived partner, it will raise a 403 error.
To reproduce the error:
1. Go to Settings > Invoicing > Customer Payments
2. Enable "Invoice Online Payment"
3. Create a customer C
- Set a name
- In Contacts & Addresses, add two contacts C_01 and C_02
- Both are "Invoice Address"
- Add a valid email for C_01
4. Go to Customers > C_01, Action, Grand portal acess
- Check "In Portal", Apply
5. Go to Settings > Users & Companies > Users
6. Remove the search filter, Select C_01, Add a password
7. Create an invoice INV
- Customer: C_02
8. Connect to C_01's account
9. Click on "Invoices & Bills"
- The invoice INV is listed
10. Connect to admin's account
11. Go to Customers, Archive C_02
12. Repeat steps 8-9
=> A 403-Forbidden page is displayed with a traceback.
For a user to have access to the "Invoices & Bills", one of the
followers of each invoice must be part of the same commercial partner:
`('message_partner_ids','child_of',[user.commercial_partner_id.id])`.
Here is the issue: if archived, the partner will not be in the
`message_partner_ids` list. This is the reason why, in our case, C_01
can no longer access the documents.
This commit allows the archived partners to be listed when getting the
portal transactions.
OPW-2417275
closesodoo/odoo#63790
X-original-commit: ad36feae0a1ee6fe0bdfbb622685a6b143ea4f2a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Demesmaeker