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>
This commit fixes two bugs, the first one is a reinstall bug that
happens whenever the modules `payment` or `payment_test` are uninstalled
then reinstalled and the second one is a bug in which for some payment
acquirers, a journal is never created.
For the first bug, the problem is that when uninstalling the
aforementioned modules, the journals linked to each provider are not
deleted (which is ok from a business POV) and thus when reinstalling
said modules we simply recreate new journals, but journals have a
unicity constraint on (name, code, company_id), therefore the
re-creation of these journals will most likely fail.
This bug doesn't happen with other payment_* modules because all *main*
acquirers are defined in the payment module, except for payment_test
that defines its own acquirer (thus the fact that it fails to reinstall
too).
The solution chosen is to try to force the creation of the journals,
even if it may fail, within a try/except block: if it does fail, we
simply do a lookup for matching (name, code, company_id) and assign
whatever we find to the acquirer's journal_id. This approach was chosen
because the most common case is that of an install (journal creation),
so checking for existing journals first would make the most common case
less performant.
For the second bug, the part of the code that creates journals for
providers being installed made a false assumption: To find the acquirers
for which to create journals, it would gather the name of the
acquirer/provider from the module name of the modules being installed
(or that were already installed) and would compare them to existing
acquirers whose provider would match the names extracted from the module
name. However, not all payment_ modules contain the actual name of the
provider in the module name! payment_ingenico is one such case, while
the module name contains ingenico, the technical name for the provider
is 'ogone', meaning that the heuristic would never find an existing
acquirer with provider set to 'ingenico', therefore no journal would be
created for that specific payment provider.
The fix is trivial, payment.acquirer has related fields that point to
the modules that implement each provider, meaning that one can simply
check for all payment.acquirer whose module_state is 'to_install' or
'installed'.
This bug does not happen in v12 because when v12 was released ogone was
still ogone and not ingenico, and all payment acquirers actually
followed the convention of module name == provider name, but for
simplicity's sake we keep this change for v12 too since it's in the same
scope as for the first bug and the code is cleaner anyway.
closesodoo/odoo#62563
X-original-commit: 0b70f188ca441d6cf53b2ef63f4856239bbee8e4
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@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>
Before this commit payment tokens had no name for Test Payment Acquirer
After this commit tokens generated by Test Payment Acquirer have a name
that combines the last 4 digits of the card number and the card account
holder name
https://github.com/odoo/odoo/issues/50965closesodoo/odoo#61848
X-original-commit: e20f0650acbd1a7a918375a70ec5c89606523a7b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
STEPS:
* install website_sale
* setup few delivery options
* setup online payment (e.g. paypal)
* at website add products to cart and proceed to checkout page
* slow down internet speed
* click "Pay now"
BEFORE: while it's loading, you can change delivery option. So, you have SO
changed, while in payment page you see old total amount
AFTER: it's not possible to change delivery options through UI
Note that it is not possible to pay less that what you should at anyway.
opw-2324543
closesodoo/odoo#61723
X-original-commit: eb3ed89f8440050fc32f9a7b29fb2b6ab8fd6b59
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
- The field 'invoice_ids' no longer exists on account.payment.
- When registering a payment using a payment token, the payment is not posted directly but the payment transaction is processed instead.
It means the payment is not posted until the CRON call. Since 14.0, the journal items can't be reconciled if not posted and then, we can't wait the CRON to update the payment state.
- The payment token is no longer available when registering a payment for invoices.
closesodoo/odoo#60918
Task: 2352628
X-original-commit: 0ad8979cb345805b7b1bdc330621b42e1d625593
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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>
Issue
- Install "eCommerce" and "Inventoy"
- Activate "Fedex" delivery connector in settings
- Publish "Free Delivery" and "Fedex US" delivery method
- Put the "FedEx" one above the "Free Delivery"
- Go to shop and add an item to cart
- Set an adress with no ZIP code and checkout
- Select a payment methode and pay
Order is generated without selecting a delivery method
Same behavior happend when using only "Fedex" as delivery
method.
Cause
The flow make the `payment.payment_form` trigger start after
`website_sale_delivery.checkout` JS module.
In 'start' function of `payment.payment_form`, the `disabled`
attribut is removed from button if no checkbox_cgv is present
and therefore break the `disabling` managemet since
`disabledReasons` payButton data are not sync anymore.
Solution
Remove 'disabled' attribut only if has `disabledReasons` data on
payButton (checkbox_cgv feature alter `disabledReasons`).
opw-2355407
opw-2357605
closesodoo/odoo#60359
X-original-commit: 04e589e80b3ef48640f275cb20d31c17c2126c69
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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 method action_validate_invoice_payment() has been removed from the base
model but is still overriden in the payment module.
This commit will remove the override.
Task id #2285897closesodoo/odoo#56278
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When a field is specified as widget="monetary" it makes sense to have the
currency actually shows. It won't happen if currency field is not present
within the view.
An heuristic to detect missing currency field presence when using monetary
fields or monetary widget tag will land soon in master. As this commit targets
a stable version only view fixes are provided.
Task ID-2329114
PR #56946
X-original-commit: 9c1c848ad1e8fef11320e2a162b008de7e304bcb
DBO won't be here anymore 👋
This is my last commit, I had to find something harmless.
Task-NaNNaNNaNNaNNaNNaN
closesodoo/odoo#56789
X-original-commit: fc92728fb2aa306bf0e01a7f9ae1cfa3c1df0e10
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Problem:
the controller rely on record rules to select the payment.token
to be displayed on the payment page.
This works fine with portal user, but internal user
will face client side performance issue
as they can see all the token of the database
Solution:
Don't rely on record.rule in the controller. Use the domain
from the portal user rule in the search.
To make the search of token working for partners with more than
2 levels of hierachy, use child_of operator
closesodoo/odoo#56326
X-original-commit: 3999e249ea9902e009f0366949886e14e3d7fdf4
Related: odoo/enterprise#12579
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
