Thursday, January 8, 2026
21 changes · saas-18.3
Enhancements to existing features
This update adjusts how Odoo handles tax exemption reasons on UBL documents, aligning with updated regulations. Now, if a tax exemption reason isn't provided, a default reason is automatically applied for relevant tax categories, ensuring compliance and accurate reporting. This simplifies the process for users and improves data consistency.
Original PR description
According to the ubl documentation the tax exemption reason code is not always required on the document. But when no exemption reason code is given, we have a default exemption reason for the appropriate tax categories. task: 5223145 Forward-Port-Of: odoo/odoo#242055 Forward-Port-Of: odoo/odoo#233770
Resolved issues and error corrections
This update corrects an issue where invoice data sent to the SInvoice system was missing descriptions and unit information. The fix now uses the line name directly and defaults to 'Units', ensuring accurate and complete data transmission for invoices. This improves the integration with the SInvoice system and reduces potential data discrepancies.
Original PR description
Currently, the item name in the data sent to the SInvoice system is comprised only of the product name on the line. This brings a few issues that should be corrected: - Any description set on the line on top of the product won't be sent - If there is no product, the required item name will be set to False - If there is no product, the required unit name will be set to False too To fix these issues, we will: - Use the line name directly and not the product name and; - Default to 'Units' for the unit name in all cases where it wouldn't be set. task-5438691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241503
This update resolves an issue where setting an invalid video link in course slides would cause a system error. The fix ensures that the system gracefully handles incorrect links, preventing disruptions to the user experience when adding or editing course content. This improves the reliability of our online learning platform.
Original PR description
When a user sets an invalid video link for a slide, a traceback occurs. Steps to reproduce the error: - Install ``website_slides`` module with demo data - Go to Website > Courses > Open Taking care…
When a user sets an invalid video link for a slide, a traceback occurs. Steps to reproduce the error: - Install ``website_slides`` module with demo data - Go to Website > Courses > Open Taking care of Trees course - Add Content > Video > Add valid video link (ex. https://www.youtube.com/shorts/SXHMnicI6Pg) > Save and Publish > Delete - Repeat above step - Add content > Video > Add any text in video link > Save and Publish Traceback: ```py AssertionError: Could not find all values of slide.slide(12,) to flush them ``` https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/website_slides/controllers/main.py#L1363-L1372 New record is created using ``new()`` to fetch external metadata for the slide. This record only exists in memory and is not stored in the database. When the video link is invalid, ``video_source_type`` is False, and the code attempts to ``unlink()`` the slide. Unlinking the record triggers field recomputations, and it will lead to the above error when flushing the new record. ref: https://github.com/odoo/odoo/commit/71233fa2cb8984b65f8e7ac55405fdbc054756a0 sentry-6964031088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235099
This update resolves an issue where users without administrator permissions encountered errors when opening duplicated reports within the Studio feature. The fix prevents a traceback by ensuring the system handles permission errors gracefully, improving the user experience for all users.
Original PR description
When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised. Steps to reproduce the error: - Install ``account`` and ``web_studio`` - Login as…
When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised. Steps to reproduce the error: - Install ``account`` and ``web_studio`` - Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo - Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report - Login as Mitchell Admin, remove administrator right of Marc Demo - In Mark Demo, Open the duplicated report Traceback: ```py UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``. For users without the required permissions, this ``search()`` raises an AccessError. https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400 Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound. However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``. sentry-7149350379 Forward-Port-Of: odoo/enterprise#103017
This update ensures that report views in Odoo Enterprise consistently generate unique keys, regardless of template status (active or inactive). Previously, inactive templates could cause duplicate keys, leading to potential customization conflicts and data inconsistencies. This fix improves the reliability and accuracy of report generation.
Original PR description
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive…
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template. After this commit: ----------------------- The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive. This ensures that template keys remain unique across all report templates. Why this commit: ----------------------- if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys. This fix prevents such conflicts by ensuring unique template key generation. Forward-Port-Of: odoo/enterprise#101894
This update fixes a potential confusion in the sales details report by ensuring payment orders are consistently displayed. The report now sorts by payment method and session, making it easier for users to understand sales transactions and improve reporting accuracy. This change enhances the overall usability of the sales reporting feature.
Original PR description
Before this commit, payment order was not guaranteed and could confuse users reviewing sales details report, especially as the cash register lines are ordered before. This commit orders the results by payment method and session to make the output more readable. opw-5240864 Forward-Port-Of: odoo/odoo#242387 Forward-Port-Of: odoo/odoo#237040
This update resolves an issue where string values entered in the web_studio field editor were incorrectly formatted with extra quotes and slashes. Now, string values are correctly displayed and saved, ensuring accurate field configuration within the studio interface. This improves data integrity and usability.
Original PR description
Have a field widget with an option of type "string" (supportedOption meta field of the widget) In studio, change the value for that option. Before this commit, the value appeared in the input as escaped: there were supplementary quotes and slashes After this commit, the string value is correctly displayed. Forward-Port-Of: odoo/enterprise#103476 Forward-Port-Of: odoo/enterprise#103364
This update resolves an issue where duplicating an invoice from a sales order would incorrectly link both the original and duplicate invoices with the same source document. The fix prevents the automatic copying of the source document during the duplication process, ensuring each invoice has its own unique link.
Original PR description
### Issue: When opening an invoice from a Sale Order and duplicating it, the Source Document (invoice_origin) was also copied As a result, both the original and duplicated invoice showed the same…
### Issue: When opening an invoice from a Sale Order and duplicating it, the Source Document (invoice_origin) was also copied As a result, both the original and duplicated invoice showed the same Sale Order in the Source Document field ### Cause: The `action_view_invoice` method adds `default_invoice_origin` in the context, causing the `copy` function to set `invoice_origin` The field invoice_origin was already set with copy=False in this PR: https://github.com/odoo/odoo/pull/236656 The default context was introduced in PR: https://github.com/odoo/odoo/pull/34561 ### Steps to reproduce: - Create a sales order (SO) - Create and confirm an invoice from the SO - Click on the `Invoices` smart button to access the invoice (SO is visible at the top) - Duplicate and confirm the invoice (The SO is not linked) - Go to the invoices list view and make the `Source Document` visible - Observe that both invoices show the same SO as their `Source Document` opw-5360172 Forward-Port-Of: odoo/odoo#239676
This update fixes an issue where the wrong manager was sometimes assigned to approval requests. The change ensures the correct manager, based on the request, is always identified, preventing errors and ensuring approvals are processed accurately. This improves the reliability of the approval workflow.
Original PR description
The previous code added the manager by searching for the first employee that matches the request_owner_id. If there are multiple such employees, it's possible that an employee from a different company than the approval can be selected. Ticket: [5185449](https://www.odoo.com/odoo/project.task/5185449) Forward-Port-Of: odoo/enterprise#99978
A recent update to the 'account_no_followup' module caused a memory error during installation on existing Odoo databases. This commit resolves the issue by initializing the module's data directly in SQL, preventing the overfill of system memory and ensuring smooth installations.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue. Forward-Port-Of: odoo/enterprise#102330
This update corrects a prioritization issue in how Odoo identifies partner names when importing account data from XML files. Previously, the contact name was favored over the legal entity name. This change, requested by CHKL, ensures the legal entity name is used as the primary identifier, improving data accuracy for legal entity reporting.
Original PR description
When we create an account.move from an XML file, Odoo first searches for an existing partner via some values fetched with `_import_retrieve_partner_vals()`. Amongst those vals, the name can be fetched from either the `Contact:Name` or the `PartyLegalEntity:RegistrationName`. Currently, the contact name is prioritized over the legal entity name. After discussion with CHKL, this should be the opposite. Discord link: https://discord.com/channels/678381219515465750/694447009679147068/1457691361959608413 Related ticket: opw-5269360 Forward-Port-Of: odoo/odoo#242405 Forward-Port-Of: odoo/odoo#242037
This update resolves a technical issue where the 'Mark as Ready' order completion process in UrbanPiper POS was failing, resulting in an 'undefined street' error. The fix ensures the system correctly checks if a customer is assigned before completing the order, preventing this error and ensuring accurate order processing.
Original PR description
Steps to produce: ==== - Place an online delivery order through urbanpiper - Edit the order and remove customer - Complete the order as Marks as Ready - Print Reciept Issue: ==== - TB occurs stating undefined street Fix: ==== - Check whether partner is assigned or not task-5407001 Forward-Port-Of: odoo/enterprise#103475 Forward-Port-Of: odoo/enterprise#102100
This update addresses a warning message that appeared when searching for payment tokens. The change adds a field to the payment token model, allowing searches to be performed using the record name instead of the display name, which was causing the warning. This ensures smoother and more reliable searching functionality.
Original PR description
address this warning: `2026-01-07 04:53:23,985 3407309 WARNING v18c_... odoo.models: Cannot search on display_name, no _rec_name or _rec_names_search defined on payment.token` Forward-Port-Of: odoo/odoo#242477
This update resolves an issue where loyalty rewards would throw errors when attempting to apply them if their associated product was archived or invalid. The system now intelligently skips loading these rewards, preventing disruptions to the POS experience and ensuring smooth operation. This improves reliability and prevents potential errors during transactions.
Original PR description
Steps: --------- - Install pos_loyalty. - Add a product to a loyalty reward’s reward product, or assign a product tag with no actual products as a reward product tag. - Archive/delete the reward product. - Open session. Issue: ---------- - A traceback appears when attempting to apply the affected reward, due to the archived/deleted or invalid reward product is being loaded in the POS. FIX: ----------- - Skip loading loyalty rewards whose reward product is archived/deleted or whose reward product tag contains no valid products. Task-5226654 Forward-Port-Of: odoo/odoo#242551 Forward-Port-Of: odoo/odoo#235081
This update resolves a bug that prevented Facebook account statistics from refreshing correctly in older versions of Odoo. The issue stemmed from a difference in how the datetime library handled timezones, specifically the format of date strings. This change ensures consistent functionality across different Python versions.
Original PR description
Bug
===
When refreshing the statistics of a Facebook account, an error can happen, depending on the datetime library version.
The following work in python 3.11, but not on python 3.10 and earlier, due to `+0000` instead of `+00:00`.
```py
import datetime
datetime.datetime.fromisoformat('2025-11-16T08:00:00+0000')
```
Task-5473117
Forward-Port-Of: odoo/enterprise#103456This update resolves a potential issue where precommit hooks in Odoo's database system could cause an infinite loop. By allowing the ORM to automatically handle flushing, the system is now more reliable and stable. This change was made in conjunction with a previous update to ensure consistent database operations.
Original PR description
In the existing implementation sometimes precommit hooks need to flush manually because they are ran after the flush is executed in the cursor. A precommit that triggers ORM changes may be not flushed unless it is done explicitly, however an explicit call may turn into an infinite loop. This removes the need to flush in precommit hooks and let the ORM handle it safely. Flushing of the environment was already done in #220379. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242248
This update resolves a test issue that was consistently failing due to a hardcoded January date. The fix adjusts the test's date reference to a more standard mid-year date, ensuring consistent test results and preventing false failures. This improves the reliability of the testing process.
Original PR description
Some tests are making "self.frozen_today - timedelta(days=1)". It means some tests are failing only the first of January. To avoid that, let's make "frozen_today" to be in the middle of the year. Forward-Port-Of: odoo/enterprise#102827 Forward-Port-Of: odoo/enterprise#102772
This update fixes an issue where the POS system incorrectly flagged refunds as exceeding order amounts due to rounding differences. The change now accounts for potential rounding discrepancies, ensuring accurate refund calculations and preventing unnecessary alerts. This improves the reliability of the POS refund process.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240 Forward-Port-Of: odoo/enterprise#103094 Forward-Port-Of: odoo/enterprise#102224
This update resolves an issue where scanning cashier barcodes would cause an error if employee logging was turned off. Now, the barcode scanning functionality in the POS HR module works correctly regardless of whether employee logging is enabled, ensuring consistent operation for all users.
Original PR description
Before this commit, if logging with employee was disabled, scanning a cashier barcode would raise an error. opw-5437310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241318 Forward-Port-Of: odoo/odoo#241131
This update resolves a visual inconsistency in Odoo reports. Previously, long company taglines would push the address off-screen when generating PDFs, leading to a mismatch between the report preview and the final printed version. The fix ensures taglines wrap correctly, maintaining a consistent and professional report layout.
Original PR description
In the report when a company_tagline is long it offsets the address outside of the visible area but only in PDF. This creates a mismatch between the preview and the PDF rendering, creating unpredictable behavior. Adding a width ensures the tagline wraps instead of pushing the address out. task-5367661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238110
This update fixes an issue with Brazil tax names that were causing errors when setting up a new company. The changes rename and translate tax names to ensure accurate accounting and prevent setup failures, improving the system's reliability for Brazilian businesses.
Original PR description
In 17.0, some taxes have had their incorrect name for the cashback taxes. This renames the invoice_label and name fields of such taxes to better represent what they are as well as add portuguese translations where necessary. task-5470453 Forward-Port-Of: odoo/odoo#242720 Forward-Port-Of: odoo/odoo#242446