Friday, January 16, 2026
12 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where placeholder hint text in the HTML editor would wrap awkwardly onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more consistent user experience. This improves readability and visual appeal.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243006
This update simplifies the GSTR report generation process by removing an unnecessary credit note warning. Previously, a warning appeared on GSTR reports when a credit note was present on an invoice, which has now been corrected. The warning is now cleared only after the credit note is fully posted and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#102106
A test related to inventory adjustments was intermittently failing due to a race condition involving notification messages. This commit resolves the issue by automatically closing the initial success notification before processing subsequent adjustments, ensuring accurate test results.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692)
This update fixes a potential issue in how the system determines if a stock location is a child of another. The change replaces a method that could incorrectly identify related locations due to matching IDs, preventing a specific test from failing. This ensures more reliable stock management processes.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update resolves an issue where the HTML editor would crash when attempting to remove formatting from a cell with a lingering color after text deletion. Now, users can reliably remove color formatting without encountering errors, improving the overall stability and usability of the HTML editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241829
This update resolves an issue where the 'product_barcodelookup' module would crash when attempting to retrieve images for products that didn't have associated images in the Barcode Lookup API. The fix ensures the code handles cases where the API returns a different data type than expected, preventing the error and allowing image retrieval to function correctly.
Original PR description
Attempting to fetch pictures for a product via the Barcode Lookup API that has no images causes a traceback. Steps to reproduce the error: - Install ``product_barcodelookup`` module and set API Key -…
Attempting to fetch pictures for a product via the Barcode Lookup API that has no images causes a traceback. Steps to reproduce the error: - Install ``product_barcodelookup`` module and set API Key - Create a new product > Barcode: ``7896539200843`` > Save - Actions > Get Pictures from Barcode Lookup > Get Pictures Traceback: ``AttributeError: 'dict' object has no attribute 'status_code'`` https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25 When a product does not have picture in barcode lookup, ``barcode_lookup_request`` method returns ``dict`` instead of ``Response`` object. This causes a traceback when the code later tries to access ``status_code`` at: https://github.com/odoo/enterprise/blob/e9bf8ee37d9fde09a1599d64b44f0c6599299cf4/product_barcodelookup/wizard/product_fetch_image_wizard.py#L277-L278 ref: https://github.com/odoo/enterprise/commit/48582d98d6a1bc275a6f6c2baa83431dda085516 sentry-6886021547
This update resolves an error that prevented users from exporting CRM forecasts. The issue stemmed from changes in how forecast data is displayed, leading to a division-by-zero error when attempting to export. The fix ensures the export functionality works reliably, regardless of the data displayed in the forecast views.
Original PR description
Currently an error occurs when we try to export CRM forecast. **Steps to replicate:** - Go to CRM > Reports > Forecast. - Click on the gear menu and click `Export All`. **Error:** `ZeroDivisionError: division by zero` **Cause:** - The error due to a modification in the List and Kanban views, which are now merged into the DynamicList. - This change resulted in the `Export All` option appearing in the CRM Forecast kanban view and forecast views can have empty stages. - The issue occurs at line [1] where `self.count` becomes zero for stages without records, leading to the error. **Solution:** - This commit solves the issue by returning default value 0 when data is empty. [1]: https://github.com/odoo/odoo/blob/6be0e8ad57c531fb88dc33e126df884430f1ab21/addons/web/controllers/export.py#L97 sentry-6720460271 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where sorting of picking records was not functioning correctly due to a technical detail in how Odoo compares related data. The change ensures that picking records are sorted accurately, improving the reliability of inventory management processes. This resolves a potential inconsistency in how the system identifies and orders related records.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512
This update resolves a technical issue that was causing an error message during Razorpay payment processing within the Point of Sale (POS) system. The fix removes an unnecessary attempt to use 'sudo' on a specific object, ensuring smooth and reliable payment transactions for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) reflecting Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for transactions involving Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects a bug where overdue invoices were printed twice in follow-up PDF reports. The issue stemmed from how the system attached invoices during manual follow-up creation. Now, invoices appear only once in the generated PDF, ensuring accurate reporting and reducing potential confusion for users.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516