Friday, January 9, 2026
17 changes · saas-18.3
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 compliance with Vietnamese financial reporting standards, taking effect starting January 2026. It impacts financial reporting within the Vietnamese Odoo version.
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 Forward-Port-Of: odoo/enterprise#103738 Forward-Port-Of: odoo/enterprise#102843
This update corrects the names and descriptions of taxes used in the Odoo accounting system for Belgium. These changes ensure accurate reporting and compliance with Belgian tax regulations. This impacts the way tax calculations are handled within the system.
Original PR description
### With this commit:- - We are updating the current tax name and its description in Belgium. - Please visit the task for more reference. task-5363874 Forward-Port-Of: odoo/odoo#242553 Forward-Port-Of: odoo/odoo#236242
Resolved issues and error corrections
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting. The change ensures that contract overlap dates are limited to the payslip period, providing more reliable payroll data. This improves the accuracy of employee time and cost tracking.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103500 Forward-Port-Of: odoo/enterprise#100700
This update resolves a technical issue that caused a traceback when users accessed the bank reconciliation popover feature in debug mode, specifically when reconciling statements with invoices in different currencies. The fix ensures the popover component functions correctly, preventing errors and improving user experience.
Original PR description
In Bank reconciliation widget, when reconciling a statement with a move in different currency, users may display a popover to access some reconciliation info. Currently, accessing this component in debug mode may raise a traceback. Steps to reproduce: - Have a Bank statement in company currency - Reconcile with an invoice in foreign currency - Go in debug mode - From the reconciliation widget, locate the reconciled bank statement - Click on the reconciled bank statement popover button Issue: Traceback is shown `OwlError: Invalid props for component 'BankRecLineInfoPopOver': 'exchangeMove' is not a object` It occurs because props validation of the Owl component will fail BankRecLineInfoPopOver opw-5355964
This update ensures that all MOA (Monthly Accounting) values within the French accounting module are positive integers. The changes involve rounding and adding a check to prevent negative values and removing unnecessary calculations. This improves the accuracy and reliability of financial reports generated for French businesses using Odoo.
Original PR description
All MOA fields should be positive integer. task-5380637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239587
This update fixes a visual issue in the email composer where long email content would overflow the message bubble, disrupting the user experience. The change makes email content scrollable within the bubble, ensuring a cleaner and more readable display for longer messages. This improves usability for sending and receiving emails.
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 Forward-Port-Of: odoo/odoo#237878
This update corrects a minor issue where typing 'B)' was automatically replaced with a 😎 emoji. This change ensures user input remains unaltered, improving the overall user experience and preventing unintended modifications to messages.
Original PR description
Before this PR, typing `B)` was automatically converted into a 😎 emoji, which could unintentionally alter user input. This PR disables that conversion. task-[5221032](https://www.odoo.com/odoo/project/1519/tasks/5221032) Forward-Port-Of: odoo/odoo#242831
This update ensures the Helpdesk dashboard's styling aligns with other Odoo dashboards, specifically addressing a formatting issue where the Top Customers pivot wasn't correctly highlighting the last row. This improves the overall visual consistency and user experience of the Helpdesk dashboard.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103019
This update resolves an issue where invoices couldn't be sent correctly due to a technical error (a 'timeout' situation). The fix corrects a problem with how error messages were handled, ensuring invoices are now sent reliably. This improves the overall stability of the Danish Nemhandel integration.
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 Forward-Port-Of: odoo/odoo#242811
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, when a refund was processed, these attributes were lost. The fix correctly transfers the attributes from the original order to the new refund order, improving the accuracy of refund records.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332
This update resolves a technical issue within the HTML editor that could cause errors when content is deleted during editing. The fix ensures the editor continues to function correctly even when all inserted content is removed, improving overall stability and user experience. This was triggered by a disconnect between selection nodes.
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 Forward-Port-Of: odoo/odoo#242488
This update resolves an issue where Google Input Tool caused errors in HTML fields, specifically when typing Arabic numbers. The fix ensures the system correctly handles `keydown` events, even those triggered by the Google Input Tool, preventing tracebacks and improving overall stability.
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 Forward-Port-Of: odoo/odoo#242498
This update prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets needing attention, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#102860 Forward-Port-Of: odoo/enterprise#52355
This update resolves an issue where the summary lines within the Barcode app appeared in a light color scheme, regardless of the user's Dark Mode setting. The fix utilizes dynamic color variables to ensure the summary lines correctly display in dark mode, improving the user experience and visual consistency across the Odoo platform.
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 Forward-Port-Of: odoo/enterprise#102270
This update fixes a data inconsistency issue in Peruvian invoices and credit notes. Previously, the document number was formatted with leading zeros, but the related name field wasn't updated. This change ensures all invoice fields are consistently formatted, improving accuracy in vendor invoices and reports.
Original PR description
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not…
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields. Steps to reproduce: 1. Create a purchase invoice for a Peruvian company 2. Select a document type (Factura, Boleta, or Credit/Debit Note) 3. Enter a document number like "F01-100" 4. Save the record 5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports. 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 Forward-Port-Of: odoo/odoo#241948
This update fixes an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The fix corrects a restriction in the system's access controls, ensuring all users with accounting rights can now view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update fixes a minor issue where discounts could result in a small, unexpected tax difference ($0.01) in sales orders. The change ensures that tax adjustments are correctly applied even when the overall tax total is zero due to discounts. This improves the accuracy 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 Forward-Port-Of: odoo/odoo#240633