Wednesday, January 21, 2026
11 changes · saas-18.3
Enhancements to existing features
This update ensures Odoo correctly handles the new 11% and 21% VAT rates introduced in Romania. By adding missing tax mappings, the system now accurately reflects the latest Romanian VAT regulations and ensures proper fiscal position calculations.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#244602 Forward-Port-Of: odoo/odoo#243452
This update optimizes how Odoo generates reports by grouping related database queries. Previously, each report filter required a separate SQL query, which was slow. Now, multiple filters targeting the same data are combined into a single query, significantly speeding up report generation times – specifically, the Generic Balance Sheet now runs in 36 seconds instead of 1 minute 35 seconds.
Original PR description
Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725 Forward-Port-Of: odoo/enterprise#101725
Resolved issues and error corrections
This update fixes an error in the Swiss VAT reporting module that was causing negative values to be displayed for reverse charge tax figures (382a and 383a). The fix adjusts how these figures are calculated to accurately reflect the reverse charge mechanism, ensuring correct VAT reporting for Swiss companies.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244613 Forward-Port-Of: odoo/odoo#244452
This update fixes a problem where the file upload service wasn't properly handling errors from different types of Odoo API responses (JSON, JSONRPC, or HTML). Now, the service is better equipped to manage these errors, leading to a more stable and reliable file upload experience. This ensures users can consistently upload files without unexpected interruptions.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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#244704
This update fixes a discrepancy in eWaybill invoices for exports to India. It now includes reverse charge (RC) amounts in the total invoice value, aligning with the Indian government's eWaybill system. This ensures accurate reporting and compliance with GST regulations.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update fixes an issue where the website's cookie consent settings weren't being saved correctly after changing the appearance of the 'I agree' button. The change in button style triggered an unintended closure of the consent modal, preventing the user's consent from being recorded. This ensures that cookie consent settings are reliably saved, improving user experience and compliance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix addressed a missing size constraint, allowing the map to render. However, the map remains non-interactive, indicating a separate problem that needs attention.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104743 Forward-Port-Of: odoo/enterprise#104114
This update creates a dedicated test company to isolate Shop Floor tests from demo data, ensuring more reliable results. It also re-enables key test tours related to Shop Floor operations, allowing for better validation of the system. This improves the quality and consistency of our Shop Floor testing procedures.
Original PR description
This PR does 2 things: ## Create a test company Add a company dedicated to TestShopFloor's tests so those tests won't be affected by demo data anymore. ## Enable tours Until then, 10 tours related to Shop Floor were skipped after [a refactor of the Shop Floor](https://github.com/odoo/enterprise/pull/80469) design and functionality. This PR re-enables 7 of these 10 tests tour (3 remaining need more work to pass when demo data are installed.) Also it adds a test helper method, `_enable_settings`, to enable wanted setting(s) easily. [task-5365014](https://www.odoo.com/odoo/966/tasks/5365014)
This update ensures that delivery carriers are consistently applied across all stages of a multi-step delivery process, regardless of whether they're initially set on the sale order or manually configured during picking. This change addresses a previous limitation where carrier settings weren't propagated, now allowing logistics teams to manage carrier selection effectively.
Original PR description
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set…
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set on a picking (e.g., during the packing step in a multi-step delivery flow), it was not propagated to the consequent pickings, even when the stock rules had `Propagation of carrier` enabled. Steps to reproduce: ================================ 1. Activate Multi-Step Routes and Delivery Methods. 2. Configure a 3-step delivery route in the warehouse and enable Propagate Carrier on all rules. 3. Create a sale order with a product but without setting a delivery carrier. 4. Confirm the sale order to generate picking. 5. On the first picking (i.e., pick), manually set a delivery carrier (e.g., Local Delivery) and validate. 6. On the next transfer (i.e., pack), observe that the delivery carrier is not propagated. After this commit: ================================ The delivery carrier set on any picking is propagated to subsequent transfers when the corresponding stock rule has `Propagation of carrier` enabled and no carrier is already configured on the next picking. This ensures consistent carrier propagation across all routing configurations (all pull rules, all push rules, and mixed push/pull flows), even when the carrier is configured at the picking level rather than on the sale order. This behavior is required because, in many business scenarios, carrier selection is managed by the logistics team rather than the sales team. task-4454313 Forward-Port-Of: odoo/odoo#202700
This update fixes a potential issue where Microsoft calendar synchronization could fail due to a short timeout when communicating with Microsoft's services. Now, administrators can adjust the timeout setting to accommodate slower environments or larger calendars, preventing synchronization failures and duplicate event creation. This enhances the reliability of calendar syncing.
Original PR description
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls…
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time. Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events. **Current behavior before PR:** Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer: • the synchronization fails, • and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo. **Desired behavior after PR is merged:** The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`. If the parameter is not set, the behavior remains unchanged (default 3 seconds). Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244461 Forward-Port-Of: odoo/odoo#241921
This update resolves a potential issue where Microsoft calendar synchronization could fail in slower environments. A previous timeout limit was too short, causing delays. This change allows for a configurable timeout, increasing the reliability of calendar syncing and ensuring appointments are properly synchronized.
Original PR description
Microsoft calendar sync can fail in slower environments due to a fixed 3s timeout for Graph requests triggered after commit. See community changes for details. Forward-Port-Of: odoo/enterprise#104916