Wednesday, May 6, 2026
15 changes · saas-19.1
New functionality added to Odoo
This update prepares Odoo for the new Belgian VAT reporting requirements, effective May 1st. It adds a dedicated 'Tax Provision Account' (411800) to ensure accurate reporting of VAT provisions, aligning with current regulations. This change simplifies VAT reporting for Belgian businesses using Odoo.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#116182 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update optimizes how the HTML editor recalculates styles during updates, leading to a smoother and faster user experience. By reducing unnecessary style calculations, the system now responds more quickly to changes, improving overall performance. This change addresses a technical issue that was causing delays in the HTML editor's responsiveness.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update corrects a bug where attachments weren't uploading correctly when navigating between records in the chatter. The fix ensures attachments are properly associated with the intended record, preventing data inconsistencies and improving the reliability of attaching files.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290 Forward-Port-Of: odoo/odoo#262714 Forward-Port-Of: odoo/odoo#261552
This update resolves a duplication issue in the Profit and Loss report for French accounting (l10n_fr_reports). The fix removes a mistakenly included account, ensuring accurate financial reporting. This improves the reliability of financial data for French-speaking customers.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update resolves an issue where Amazon's fulfillment channel data caused stock synchronization problems. The system now uses a more reliable field from the Listings API to determine channel availability, defaulting to FBM when necessary. This ensures accurate stock updates and avoids disruptions in Amazon sales.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#115899 Forward-Port-Of: odoo/enterprise#114473
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. The problem stemmed from a previous update removing a necessary session ID. This fix restores the session ID, allowing refunds to function as intended and ensuring accurate payment reversals. A new test tour has also been added to verify the full refund process.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262788 Forward-Port-Of: odoo/odoo#262475
This update corrects a rounding error that occurred when importing purchase orders processed through OCR. The fix restores the standard rounding precision, which was originally designed for EDI, rather than the OCR process. This ensures accurate invoice calculations and prevents discrepancies.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly appearing in the Mod347 BOE export. The fix removes a redundant search process that was adding partners unnecessarily, ensuring only relevant partners are included based on the primary export requirements. This improves the accuracy of the BOE reports for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#115744 Forward-Port-Of: odoo/enterprise#110947
This update resolves an issue preventing employees from directly modifying their work location within the system's preferences. The change utilizes a specific function to correctly handle access to employee data, addressing a restriction introduced in a previous update. This allows employees to accurately reflect their work arrangements.
Original PR description
**Steps to reproduce** - Have a user without HR rights and linked to an employee - With this user, open Preferences and in the calendar tab and try to change the work location for one of the days - Error: You do not have enough rights to access the field "version_id" on Employee (hr.employee). **Cause** Issue after 72ac4b03657d617644ae75f2957aaec7acf6c1a8 which removed SELF_READABLE_FIELDS and SELF_WRITEABLE_FIELDS. **Change** Use the `field_employee` function introduced in 9605045313953b4c8c734c0d52e8032e3c36bf3a (commit message contains the explanation as to why it is necessary for fields coming from the employee model). opw-6127522
This update resolves an issue where quantities were incorrectly doubled when settling sales orders in POS with the 'Pick then Deliver' warehouse method. The fix ensures accurate lot tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order settlements.
Original PR description
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading…
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots. Steps to reproduce: ------------------- * Create a product with Tracking by lots * In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)" * Create a quotation with the product and confirm it * Validate the delivery * In POS, settle the sale order from Quotation/Order * When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes > Observation: Quantity doubled. Why the fix: ------------ read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice. We now use move lines from exactly one picking and filter by sale_line_id. opw-6001585 Forward-Port-Of: odoo/odoo#262237 Forward-Port-Of: odoo/odoo#253539
This update optimizes how Odoo searches for products, specifically when using 'like' operators in domain filters. The change utilizes 'UNION ALL' instead of 'OR', allowing the database to efficiently use indexes and significantly reducing search times. This results in a faster and more responsive product search experience, especially with large product catalogs.
Original PR description
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product…
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.
When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.
Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.
In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.
#### speedup
In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.
In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.
opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239369
Forward-Port-Of: odoo/odoo#229275This update resolves an issue where custom snippets weren't correctly applying translated content when using the delayed translation feature. The change ensures that translated values are properly reflected in the second language version of a website page, improving the consistency of multilingual content. This fix addresses a bug impacting the website builder's functionality.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#245850
This update fixes an issue where the table menu options weren't updating when users switched to different cells. The change ensures that the menu accurately reflects the current target cell by updating values in real-time. This improves the user experience and prevents incorrect menu options being displayed.
Original PR description
After this commit [1], setup is executed only on the initial mount of the table menu and not on subsequent target cell changes. As a result, colItems, rowItems, and other values found in setup become stale, causing the menu to display options that do not reflect the current target cell. This commit moves the necessary values from setup into useEffect so they update correctly when the target cell changes. task-6111986 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Backport of Commit https://github.com/odoo/odoo/commit/729c45ddf3d1e377507d93997c5ca45984d64d75 Forward-Port-Of: odoo/odoo#260435 Forward-Port-Of: odoo/odoo#258590
This update fixes an issue where the product carousel displayed fewer than 16 products when a product had over 256 variants. The fix removes a previous workaround that artificially increased search limits, allowing the carousel to accurately display products with a large number of variations. This ensures a better user experience when browsing products with many options.
Original PR description
# How to reproduce - Create a Product with more than 256 variants - Publish it to the website - Go to the website and add a Product Carousel - Set it to display newest products & hide variants # The…
# How to reproduce - Create a Product with more than 256 variants - Publish it to the website - Go to the website and add a Product Carousel - Set it to display newest products & hide variants # The problem Fewer than 16 products are displayed # Cause This issue was already adressed by this commit : https://github.com/odoo/odoo/pull/195857 But because of limitations for specifically the "Newest Products" filter (cf. original commit message), the fix was only a workaround. Indeed, it increased the search limit to 256 before filtering out the variants, which caused problems when there was more than 256 variants. But since then, big changes made in 19.0 has allowed us to implement a better fix : https://github.com/odoo/odoo/commit/e3b062e5d3820 # Proposed Solution Since we can now pass the model in the options : https://github.com/odoo/odoo/blob/b5069328734e623c12b0de50a177d501f7f0c995/addons/website/models/website_snippet_filter.py#L90 We give "product.template" when the `hide_variants` option is enabled and we filter on products. This allows use to remove the whole workaround that needed increase the limit on product searchs then getting their templates. A recent commit blocks passing "product.template" since it does not have a dedicated snippet filter : https://github.com/odoo/odoo/pull/257208/changes/8e264ae4ea6ae16bbd410ac384733ff8759938a6 But in the commit message, they mention that this targets snippet in single-record mode, which is not our case. So, we move the logic to only be applied for single-record filters opw-6054059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260340
This update resolves a problem where Nilvera was not sending recently created invoices to Odoo. The change extends the date range used to fetch invoices by 3 hours to align with Nilvera's timezone (Istanbul), ensuring that all invoices are synchronized correctly. This prevents data loss and improves the reliability of the integration.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera does not return recently created documents (within ~3 hours), which can lead to missing invoices during synchronization. # Current behavior before PR: The end_date was set to the current time, causing recently created documents to be excluded from the fetch results. # Desired behavior after PR is merged: The end_date is extended by 3 hours (TR GMT+3), ensuring recently created documents are included and not missed during synchronization. task-id: [6123171](https://www.odoo.com/odoo/my-tasks/6123171) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#259306