Friday, December 20, 2024
12 changes · 18.0
Resolved issues and error corrections
This fix prevents the Point of Sale from showing a confusing technical dialog when a Stripe Terminal payment setup is invalid. Users now see the real error message, while detailed information is logged for support teams to diagnose the issue faster.
Original PR description
Before this commit: 1. Install pos_stripe & pos_restaurant 2. Create a PoS payment method wish Stripe Terminal setup with dummy (wrong) value. ! Purposfully DON'T set up the Stripe account (so let it…
Before this commit:
1. Install pos_stripe & pos_restaurant
2. Create a PoS payment method wish Stripe Terminal setup with dummy (wrong) value. ! Purposfully DON'T set up the Stripe account (so let it as deactivate)
3. Add the payment method to the bar PoS
4. Open the bar PoS, make an order and try to pay by the stripe payment method
=> JS error
```js
undefined
undefined
OwlError: Invalid props for component 'AlertDialog': 'body' is not a string
Error: Invalid props for component 'AlertDialog': 'body' is not a string
at Object.validateProps (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:11392:19) (/web/static/lib/owl/owl.js:3160)
at DialogWrapper.template (eval at compile (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:13846:20), <anonymous>:10:13) (/web/static/lib/owl/owl.js:5614)
at Fiber._render (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:9961:38) (/web/static/lib/owl/owl.js:1729)
at Fiber.render (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:9953:18) (/web/static/lib/owl/owl.js:1721)
at ComponentNode.initiateRender (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:10633:23) (/web/static/lib/owl/owl.js:2401)
```
This error hide the real error as the error dialog expect to receive a string while it receive an Error object
After this commit:
The (real) error is logged to the console:
```js
payment_stripe.js:272 SyntaxError: "undefined" is not valid JSON
at JSON.parse (<anonymous>)
at Proxy.connectReader (payment_stripe.js:87:1)
at Proxy.checkReader (payment_stripe.js:79:1)
at Proxy.send_payment_request (payment_stripe.js:268:1)
at async Proxy.pay (pos_payment.js:74:1)
at async PaymentScreen.sendPaymentRequest (payment_screen.js:545:1)
```
and the error dialog shows with the string of the error, here: `SyntaxError: "undefined" is not valid JSON`
We will not have the traceback in the client message as I didn't find a way to do so except letting the error propagate. But this might have side effects so I didn't used this option.
opw-4375876This fix keeps Peppol demo-mode handling separate from Italian EDI requests. It prevents an error that could interrupt electronic invoicing flows when the two services use different request information.
Original PR description
The problem was that the decorator would be triggered if Peppol is in demo mode, but also for the requests made by the Italian EDI which does not have the same information which results in a traceback. opw-4421483 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product pages now show the correct tags when shoppers select different product variants. This helps customers see accurate product information and prevents variant-specific labels from being missed in the online shop.
Original PR description
Steps to reproduce:
------------------
- Set a product tag for a specific variant.
- Go to the shop.
- Select different variants of the product.
Issue:
-----
The tags of the variant is not shown. This is due to the JS file: odoo/addons/website_sale/static/src/js/sale_variant_mixin.js In this file we set the parent to:
var $parent = $(ev.target).closest('.js_product'); To update the product tags we do a find('.o_product_tags') However this falls outside of the div of the parent. This "find" then results with nothing. And nothing is updated.
Fix:
----
To fix this the call to website_sale.product_tags was inserted inside the right div so it can be found and thus updated.
opw-4357477
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an installation issue for modules that depend on Python packages with hyphens in their names, such as google-auth-oauthlib. These modules can now be installed correctly even when the optional packaging library is not available.
Original PR description
Some modules may have python packages with hyphen in the external_dependies (google-auth-oauthlib, ...) Those module cannot be installed anymore. Fixing the regex to allow hyphen in external dependencies when packaging is not installed.
The point of sale demo data now correctly applies the default category ordering on the product screen. This helps demo shops and restaurants show product categories in the intended order, making the POS interface clearer and more consistent.
Original PR description
In this commit: === - Ensured that the default sequence defined for POS categories is properly reflected on the product screen in the POS interface. task-4365434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This reverts an earlier mistaken change in the Vietnam localization migration process. It helps keep the module upgrade path aligned with the intended behavior and reduces the risk of incorrect data handling during migrations.
Original PR description
Undo the change made in error in the following PR : https://github.com/odoo/odoo/pull/190559/
The overdue invoice filter now only shows invoices that are unpaid or partially paid. This prevents invoices already in the payment process from appearing as overdue, giving users a more accurate view of outstanding debts.
Original PR description
Steps to reproduce: ------------------ - Go to invoices - filters on "Overdue" - Filter includes "in_payment" Issue: ----- This is not intended, the overdue filter should only include the not paid and partial. Fix: --- Removed it. opw-4383117 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce: - Install the l10n_cl module - Create an invoice - Some terms are not translated : - Incorrect: Net Amount - Correct: Total Neto - Incorrect: Exempt Amount - Correct: Total sin Impuestos - Incorrect: VAT - Correct: IVA - Incorrect: The VAT tax of this boleta is: - Correct: El IVA de esta boleta es: Issue: Some translation were missing making it incorect for the Chile localization. Fix: Updated the .pot and the .po accordingly to includ
Original PR description
Steps to reproduce: - Install the l10n_cl module - Create an invoice - Some terms are not translated : - Incorrect: Net Amount - Correct: Total Neto - Incorrect: Exempt Amount - Correct: Total sin Impuestos - Incorrect: VAT - Correct: IVA - Incorrect: The VAT tax of this boleta is: - Correct: El IVA de esta boleta es: Issue: Some translation were missing making it incorect for the Chile localization. Fix: Updated the .pot and the .po accordingly to include the terms so the translation is correct. opw-4329049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Reversed accounting documents are no longer treated as overdue in the customer portal. This prevents customers from seeing misleading payment warnings for amounts they should not pay.
Original PR description
We should never consider 'reversed' move as overdue, otherwise the user might get a warning when it connect to its portal and are encouraged to pay it whereas it should not be paid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where some messaging menu entries could fail or show the wrong conversation name after a previous backport. The change ensures regular records and discussion channels use the correct name source, keeping messaging notifications reliable for users.
Original PR description
Follow-up of [1] PR above was a backport of some improvements made in master [2]. The original PR was using `thread.display_name`, from a recent other improvement in master that split `channel.name`…
Follow-up of [1] PR above was a backport of some improvements made in master [2]. The original PR was using `thread.display_name`, from a recent other improvement in master that split `channel.name` and `thread.display_name` for clarity on the actual python field being used in client-side code [3]. The backport version [1] changed `thread.display_name` to `thread.name`, because the web client has to receive thread name from server in formatted data as `name`. However, the commit forgot that the internal formatter of thread had to pass `display_name` in the named field, and under-the-hood it is turning it into the expected `name` [4]. This commit fixes the issue by passing `display_name` as expected for non-channels. Note that channel's `display_name` is not the same as `name`, and we must always `name` for them rather than `display_name`, hence the enforced `"name"` for discuss channels. [1]: https://github.com/odoo/odoo/pull/190486 [2]: https://github.com/odoo/odoo/pull/189805 [3]: https://github.com/odoo/odoo/pull/190243 [4]: https://github.com/odoo/odoo/blob/18.0/addons/mail/models/mail_thread.py#L4607 opw-4412441 opw-4415546
This fix updates internal automated checks so they first select the correct company folder before looking for test documents. It helps keep document spreadsheet workflows stable after pagination changes limited which folders appear by default.
Original PR description
Changes from the PR(ENT)https://github.com/odoo/enterprise/pull/73443 break some tours in documents_spreadsheet (create empty sheet, clone xlsx, create template and save multipage). They all fail to find the Test folder's Kanban record in the Kanban view. PR#73443 limits the number of records per page. Tours open 'Documents' on 'Home' and 'Test folder' belongs to 'COMPANY'. When there is a large number of records, 'Test folder' is not displayed in the Kanban view. So one adds a prior step to select COMPANY before checking for the Test folder's Kanban record. task-4394473 see https://github.com/odoo/enterprise/pull/73443 see runbot error 109604
Point of Sale orders are no longer incorrectly removed when the Urban Piper module is installed but not configured. This helps businesses keep order data available in the POS cache even if the integration is not actively set up.
Original PR description
When the pos_urban_piper module is installed but not configured in the PoS settings, the orders were being filtered out incorrectly. opw-4423378