- 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>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Steps to reproduce:
- Go to the website shop
- Add a product in the cart
- Add your address and click on checkout
- On the checkout, enable Terms & conditions
Bug:
The button was always enabled even if the check box with the terms & conditions were not
checked.
opw:2313437
closesodoo/odoo#55821
X-original-commit: 0415da51960819ec9c989e15a9229bd6d583ba1b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Before this commit the tokens from payment providers (PayPal, Stripe) are shown in plain text in the onboarding wizard.
This means that anyone with accounting rights can grab & copy tokens for PayPal & Stripe.
After this commit they're shielded off with a password=True option so they're not directly readable and copyable.
Steps to reproduce: Open an Odoo instance, go to Accounting > Invoices and click on the 'Set Payments' option for the onboarding wizard.
Next choose Paypal or Credit card in the dialog and see how tokens are shown in plain-text.
closesodoo/odoo#54861
X-original-commit: 65e201ecee3bc145c2ae76d59b6d2fd31c737872
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Select a sales order.
Go to action > generate payment link.
Open private browser, reach the link.
User will receive error message because of access denied to the
res.partner data.
opw-2287534
closesodoo/odoo#54808
X-original-commit: 3b4f3a8ad2880721cf6de9fb08387412df85d356
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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
In Sales, in Payment Link generation wizard, when entering manually the total of the quotation
as Amount, it can happen that the Validation Error asking to set an Amount smaller than the total
is triggered.
opw-2287794
closesodoo/odoo#54309
X-original-commit: a7034b75383f23f309d97a86cbde7d9f8176ed6d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Go to Accounting / Customers / Invoices
- Pick any invoice not paid
- Action: Generate a Payment Link
- Open the link
- Refresh the page having Javascript disabled
- Click the Pay Now button
Traceback
Cause
If JS is not loaded, the values in the form fields are
not bound as expected.
It can also happen with slow connections and fast click
on the button at the loading. Before the JS is entirely
loaded (as it is lazy-loaded).
Solution
Button disabled by default, wait the page to be loaded
and then activate the button
OPW-2255760
closesodoo/odoo#54128
X-original-commit: 0e7071f249e69c5cca519ec66120530eb0f97153
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Install payment
Archive the cron
Upgrade system
--> Issue the cron is now active
Note: on testing server we archive cron (we make a an SQL query before upgrade the system)
@qdp-odoo
@nim-odoo
@sla-subteno-it
closesodoo/odoo#53658
X-original-commit: a47f0249d35da805436e33d06800988ca4c3b6a9
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Install 3 payment providers:
P1: no countries set
P2: country set to USA
P3: country set to Canada
- Activate online payment of invoices
- Create an invoice for portal user A (country of user is USA)
- Login with A
- Pay the invoice
All 3 providers are available, while only 1 & 2 should be available.
The providers are filtered in the sale module, but not in the account
module:
https://github.com/odoo/odoo/blob/586ee04a6296c13868011b3afaca61be5c6ff3c6/addons/sale/controllers/portal.py#L190-L193
The same issue occurs with the direct link `/website_payment/pay`.
We apply the same filtering in all modules.
opw-2279710
closesodoo/odoo#53483
X-original-commit: aaac93b551e2a5f331dd14ee5aefbe4ced173691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Security rules are added in the sale module for transactions and tokens,
but it is entirely possible to have the payment module without those,
and preventing invcoicing users from accessing transactions is
functionnaly stupid - they are often required to check payment statuses,
references, etc.
closesodoo/odoo#52139
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
As some payment acquirers require the email to be set,
a warning is shown when generating a payment link if
the partner does not have an email.
OPW-2254011
closesodoo/odoo#51857
X-original-commit: 6f61e89ab9b947ca54cfd8dbd5470083a625d24e
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Steps to reproduce:
- install sales, ecommerce and payment_authorize
- setup authorize.net (test mode)
- go to sales and select the quotation S00007 (demo data) or create a quotation
with multiple items that add up to a float
- select action > generate a payment link > go to the link > select pay with authorize
- you are redirected to authorize.net use 4111 1111 1111 1111 as card number and 1223
as expiration date > pay
- you are redirected to the odoo payment process page
- wait for the result
Previous behavior:
the user is returned to a 404 error page but the payment went trough
Current behavior:
access_token generation is consistent and will not fail because of
float representation
the user is returned to the "payment confirmed" page
WARNINGS:
- watching the values in vscode prevents bug reproduction
- when setting up authorize.net, do not forget to add your test url to
the account's allowed return urls
- use https for authorize.net connection
opw-2223135
closesodoo/odoo#50633
X-original-commit: 0fe7fa0f95b7393d8829ba4b216d6c41d0c0dc3d
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Currently, When using the "Generate a Payment Link" button under the
Action menu (model=account.move), the last step of the flow is "back
to my account" , But this button doesn't generate any actions. If you
click on it, nothing happens because the button "Back to My Account"
was overlap by the payment logo.
So in this commit, we add fix the layout and use the row so the
elements do not ovelap each other.
Task-Id : 2197705
closes odoo/odoo#49012
Closes: #49012
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When we uninstall a payment acquirer, its state should be `disabled`
because when we succedingly reinstall it, we want the
required_if_provider fields to possibly be unset (which is only possible
if the state is not in `enabled` or `test`).
opw-2223094
closes#49033closesodoo/odoo#49061
X-original-commit: ddf07ef2d9741d1db546efb1364718ff9e247aaf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- The payment link generated by using the wizard
`payment.link.wizard` are overriden to generate
URL linked to sale orders.
If so, we want the payment acquirer displayed to
be in the same company as the sale order.
closesodoo/odoo#49018
X-original-commit: 8c299efb6cb4355cec39cdedd8d7c3134f53d199
Signed-off-by: Toufik Benjaa (tbe) <tbe@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>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This code adapts all business code instances of calls to
`resolve_2many_commands` and replaces them by calls to `new` which
returns a record-like object whose api is more familiar than the
`resolve_2many_commands` api.
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Before this commit, each module override _get_translation_frontend_modules_domain
from ir.http to add its own translation in website if needed and that module
is not starting by website_. Updating the domain from the super() call.
Since we know in most of the case the name, it is useless to do a:
select name from module where name = 'name1' or name = 'name2'...
Now we support a new override of _get_translation_frontend_modules_name that will
allow to add the known module name directly in the list instead to make a search.
In case nobody override _get_translation_frontend_modules_domain, we don't need to
make an extra rpc to find the module.
Related to #47257
task-2211013
X-original-commit: 0dc54814161ab55c34dd2242f65dea23d19fdfca
Martin Trigaux