Thursday, January 8, 2026
15 changes · 18.0
Enhancements to existing features
This update adjusts the chart of accounts for Odoo's Vietnamese localization to align with recent accounting regulations (Circular 99/2025). This change is necessary to ensure accurate financial reporting starting in January 2026, reflecting current Vietnamese accounting standards.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470
Resolved issues and error corrections
This update corrects a technical issue preventing the correct loading of Brazil's chart of accounts. The fix involves renaming duplicate tax names and updating translations to ensure data consistency within the Odoo system. This resolves a problem that impacted company setup and reporting.
Original PR description
Some Brazil taxes share the same name which goes against the established constraint on the model. It was never caught before because these taxes are disabled by default, and the constraint only looks at active taxes. However, if you create a blank company and then manually load the Brazil chart of accounts via settings, it will fail to load because of a line in `res.config.settings` function `set_value()` that disables the active test. The fix here is to rename some of the taxes that have the same name as others as well as update the portugese translations of some. task-5470453 Forward-Port-Of: odoo/odoo#242446
This update corrects a technical issue where duplicate template keys were generated for report views, regardless of template status (active or inactive). This ensures consistent and accurate report generation, preventing potential customization conflicts and data inconsistencies. It improves the reliability of report views within the Enterprise module.
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
A recent change prevented users from selecting analytic items when adding a new item in the accounting module. This update corrects a bug introduced by a previous code modification that blocked the opening of the item's form view. The issue has been resolved by reverting the problematic change and restoring the original functionality.
Original PR description
Amls are not selectable from the modal on analytic items Steps: - Go to Accounting > Analytic Items - Select new - Open Journal Item selection field and click on 'Search More' - Select a line -> Nothing happen The bug has been introduced by 5a5f59471e827a369ee040d9bd4acb70e2b2348c that overrides `openRecord` to prevent the default form view to be opened when clicking on the line. This issue has been properly fixed with https://github.com/odoo/odoo/commit/295995896550f7ea389b7dc799631fa7213fd5cb therefore we can revert 5a5f59471e827a369ee040d9bd4acb70e2b2348c opw-5359355
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 field 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 and added, preventing potential 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
This update resolves an issue where summary lines in the Barcode app appeared in light colors when Dark Mode was enabled. The fix utilizes variables to dynamically adjust background colors based on selection status, ensuring consistent appearance across both light and dark themes. This improves the user experience for all users, regardless of their preferred theme.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654
This update resolves a technical issue where Google Input Tool, specifically when typing Arabic numbers, was causing errors in Odoo's HTML editor fields. The fix ensures the system correctly handles `keydown` events, preventing tracebacks and improving overall stability when using the Google Input Tool.
Original PR description
Problem: When using Google Input Tool, typing Arabic numbers causes a traceback in HTML fields. Cause: The tool triggers a fake `keydown` event without the `key` attribute. This is failing before c10fd06320b013057831a6a46b2922b5386b71ef. Solution: Explicitly check that the `key` attribute exists on the event before using it. Steps to reproduce: - Install Google Input Tool in your browser. - Open any HTML field. - Add any character using the extension. - Observe a traceback. opw-5447680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a UI issue where long email messages would overflow their bubbles, causing a broken display. The change makes email content scrollable within the message bubble, ensuring a cleaner and more user-friendly experience when viewing email notifications.
Original PR description
Current behavior before PR: When the email template (message_type = `comment`) has content that is longer (in width), the content tends to overflow out of the bubble which breaks the UI. Desired behavior after PR is merged: This commit fixes the issue by making the content scrollable inside the bubble. Task-5363388 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the HTML editor that caused an infinite loop when attempting to remove formatting from cells with lingering colored elements. Previously, deleting text and leaving a colored cell would crash the editor. Now, removing the format button correctly removes the color, improving stability and user experience.
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
This update resolves a technical issue that caused a traceback when invoices timed out during sending. The fix corrects an error in the code related to how user error messages were handled, ensuring invoices are now sent reliably. This improves the overall stability of the Nemhandel module.
Original PR description
In case of timeout when sending an invoice there is a traceback due to the following error. ``` AttributeError: 'UserError' object has no attribute 'message' ``` It is fixed in this commit. task-None
This update resolves a technical issue within the HTML editor that could cause errors when content is fully removed after editing. The fix ensures the editor doesn't attempt to set selections on nodes that no longer exist in the DOM, improving stability and preventing unexpected errors.
Original PR description
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`,…
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`, and some specific `<br>` nodes. Ultimately, the selection is set after the last inserted node. In some cases, none of the inserted content remains after the clean up. When this happens, the selection is being set after the last inserted node, which is not part of the DOM anymore, and therefore leads to an error. This commit prevents this from happening by detecting when all inserted content was actually already removed. Steps to reproduce: - In a plain web page, copy a <br> into the clipboard - In an editor, put a character on a line - Paste => An error popup was displayed task-5429909 [FIX] html_editor: avoid failing when selection nodes are disconnected This commit addresses a traceback that was spotted but for which the actual scenario remains undetermined. The only possible way this traceback may occur is if nodes inside a selection are disconnected. The test added by this commit produces the same traceback as the observed one. task-5429909
This update fixes a minor issue where discounts resulted in a small, unexpected VAT difference in order totals. The change adjusts how the system distributes tax details, ensuring accurate calculations even with significant discounts. This improves the reliability of order totals.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set tax rounding to "Round Globally"; 2. create a 19.99% tax; 3. create a new sales order; 4. add a line with a $19.99 unit price & 19.99% tax; 5. add a second line with identical values; 6. apply a 100% global discount (-$38.98 subtotal, -$47.97 total). Issue ----- The order total is $0.01 due to VAT. Cause ----- The `_round_tax_details_tax_amounts` method distributes the "tax delta" across the tax details, but currently it only does this if there's a non-zero target tax amount. In our scenario, we have a $0.01 tax delta, but because our tax total is $0.00 due to the 100% discount, the delta doesn't get distributed, leading to the $0.01 difference not getting corrected. Solution -------- When deciding whether to distribute a tax delta, check the tax delta value instead of the target tax amount. opw-5345538 opw-5097907
This update resolves an issue where refreshing Facebook account statistics would occasionally fail due to a difference in how date/time information was handled across Python versions. The fix ensures consistent date formatting, preventing errors that occurred with older Python environments. This improves the reliability of Facebook statistics reporting.
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 an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The fix applies a standard image scaling method ('object-fit: cover') to ensure avatars are displayed correctly and consistently across all user profiles. This improves the overall user experience and visual presentation.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242320