Daily updates from Odoo
Friday, December 20, 2024
26 changes
2 changes
Resolved issues and error corrections
Point of Sale now includes lot and serial number information for products stored in sub-locations. This helps staff select the correct tracked products during sales and reduces stock visibility issues.
Original PR description
Also display lot/serial numbers products that are located in sub-locations. opw: 4415220 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
This fixes a small issue in the Discuss/mail area where a chat channel might not open as intended when the system explicitly asks it to. It helps ensure users are taken directly to the relevant conversation instead of seeing it folded or hidden.
Original PR description
Following 17fa8a4531df0cd7281962211797ba60df06f775, `force_open` was introduced as a parameter to the function, but the condition to set the folding state references `open` (python's default function to open a file), not `force_open` (the parameter), probably a typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
17 changes
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.
This fix prevents accounting reports from crashing when users select multiple companies that use different currencies. It ensures date values are handled consistently so reports can load reliably in multi-company setups.
Original PR description
Steps: - Have 2 companies with different currencies - Select both in company selector - Go to any report - Traceback: `psycopg2.errors.UndefinedFunction: operator does not exist: text >= date` Cause: https://github.com/odoo/odoo/blob/cacf3fd9fda3624193e6668e7d3e311707db5dad/addons/account/models/res_currency.py#L211 this condition is never met because the NULL value is casted as a text, therefore we ends up trying comparing 'NULL' to '<date>'. Fix: Casting both `date_from` and `date_to` into date format opw-4367588
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/
This fix ensures invoices using global tax rounding calculate the final total from the unrounded base amount, then derive the displayed base consistently. It prevents small one-cent discrepancies in tax summaries and invoice totals, improving accounting accuracy.
Original PR description
Setup the round globally. Suppose a tax of 23% applied on 2 lines: quantity=1, price_unit=0.5 quantity=12.12, price_unit=12.12 Current behavior: base: (12.12 * 12.12) + 0.5 = 147.3944 ≃ 147.39 tax: 147.3944 * 0.23 = 33.900712 ≃ 33.9 total: 147.39 + 33.9 = 181.29 Expected behavior: raw_base: (12.12 * 12.12) + 0.5 = 147.3944 total: 147.3944 * 1.23 = 181.295112 ≃ 181.3 tax: 147.3944 * 0.23 = 33.900712 ≃ 33.9 (same) base: 181.3 - 33.9 = 147.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This fixes an issue where financial reports could crash when users selected multiple companies with different currencies. The correction ensures currency date values are handled consistently, so affected reports open reliably in multi-company setups.
Original PR description
Steps: - Have 2 companies with different currencies - Select both in company selector - Go to any report - Traceback: `psycopg2.errors.UndefinedFunction: operator does not exist: text >= date` Cause: https://github.com/odoo/odoo/blob/686d098d59a6078e264c8b2633020b23c5902702/addons/account/models/res_currency.py#L211 this condition is never met because the NULL value is casted as a text, therefore we ends up trying comparing 'NULL' to '<date>'. Fix: Casting both `date_from` and `date_to` into date format opw-4367588
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 Italian point-of-sale pricing so calculations consistently treat prices as tax-included where required. It helps prevent checkout totals and tax amounts from being shown or recorded incorrectly for Italian POS transactions.
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
Online food delivery order calculations now use Odoo's standard calculation method instead of custom manual logic. This reduces the risk of incorrect totals for UrbanPiper, Swiggy, and Zomato orders and makes future maintenance easier.
Original PR description
After this commit : ==== - Replace manual calculation with predefined method to enhance reliability and maintainability. task-4405397
7 changes
Resolved issues and error corrections
This update fixes a minor issue in the Approvals workflow tour. The previous method of selecting status options relied on an outdated attribute, which is now removed. The fix ensures the tour correctly identifies and interacts with the status selection buttons, providing a smoother user experience.
Original PR description
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#72063
This update resolves an issue where the "Request Cancel" button on payments for Mexican companies (l10n_mx) was not working correctly. The fix ensures the correct cancellation process is initiated, allowing users to properly request the cancellation of CFDI payments as required by Mexican regulations. This improves compliance and reduces potential errors.
Original PR description
### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create an invoice with a Mexican partner and confirm
- Create a Payment
- In the invoice form view, go to the "CFDI" page
- Click "Update CFDI"
- The payment appears, click on "Show"
- The button "Request Cancel" does nothing
### Cause:
the method `button_request_cancel` on move is called from the payment model but does not return anything:
```
def button_request_cancel(self):
self.move_id.button_request_cancel()
```
But the `button_request_cancel` from `l10n_mx_edi` is returning a wizard that is never caught.
### Solution:
When clicking the "Request cancel" button, the method `action_request_cancel` is called instead of `action_cancel` which will dispatch the request depending on the type of move being cancelled.
opw-4332483This update resolves an issue preventing non-administrator users from accessing attachments linked to Global Invoices in the Mexican CFDI localization. The fix ensures the correct link between the Global Invoice document and its attachment, allowing authorized users to view the necessary invoice information. This improves usability for users generating and managing Mexican CFDI invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create…
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and linked to the Global Invoice `l10n_mx_edi.document`, but if the link from document to attachment is complete, the opposite is not the case. `ir.attachment.res_id` has a value of 0, and, when checking access rights for `ir.attachment`, we will use the `_search` method in which one of three conditions, two of them having a `res_id` check, must be fulfilled for `ir.attachment` to be considered available to the user. https://github.com/odoo/odoo/blob/afdfbc4041f167ba6d6ff6c17b8432eb531df6b1/odoo/addons/base/models/ir_attachment.py#L561-L570 A user that did not Create Global Invoice and without `base.group_system` in their `groups_id` fulfills none of those conditions. ### Fix reasoning: The issue lies more within `res_id` not being `l10n_mx_edi.document.id` rather than a flaw in `_search`. This change should only apply when creating a Global Invoice. When sending an Invoice to the CFDI through the regular `action_send_and_print` process, `ir.attachment` is linked to `account.move` instead. opw-4365535
This update resolves a bug where the OdooEditor was incorrectly removing spans without attributes, disrupting translation matching. By preventing this removal, the system now correctly uses span keys for accurate translations, ensuring consistent localization across the platform. This improves the quality and reliability of reports for international users.
Original PR description
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++]
This update corrects a recent change that was causing issues with XML exports for customer data. We've removed a redundant data field ('FixedEstablishment') from the reports, as it's no longer needed. This ensures consistent and accurate report generation.
Original PR description
On a previous commit: https://github.com/odoo/enterprise/commit/8e2957c238e28b8a952c0e354c46e39b1fdd03a6 We changed the condition on the VATNumber node on oss report, but actually it was a mistake and in some cases, this change broke some xml exports on other customer db. But, after more investigation, we decided to remove the fixedEstablishment node from the xml export, as we don't have any use cases where this node is required for now. no task Forward-Port-Of: odoo/enterprise#75705
This update resolves an issue where product prices in the l10n_ke_edi_oscu module were not including the correct decimal precision, leading to potential errors in VAT reporting for Kenyan businesses. The fix ensures accurate price calculations, improving the reliability of financial data within Odoo Enterprise. This impacts the accuracy of sales and inventory reporting related to products subject to Kenyan VAT.
A bug causing errors when applying discounts to rental orders has been resolved. The fix ensures the system correctly handles rental products and discount programs, preventing a traceback error related to incorrect data types. This improves the reliability of rental order discounts.
Original PR description
Steps to reproduce: - In the rental module, set a product as storable and uncheck 'Out-of-Stock: Continue Selling.' - Create a discount program for product purchase with 'Get Free Product' reward. - Add enough rental products to an order on the website to trigger the discount. Issue: - Traceback error: TypeError: < not supported between instances of datetime.datetime and bool. Cause: - The reward_line has reservation_begin = False, which results in a dictionary containing a False value alongside other datetime objects. Fix: - Filter the lines to ensure the loop iterates only over rental lines. opw-4360396