Thursday, April 30, 2026
19 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where invoices rejected by the Italian tax system (SdI) remained marked as 'sent' in Odoo, preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing for correct resubmission and streamlining the invoicing process. This ensures Italian businesses can quickly correct errors and avoid delays.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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#260591
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing certain tests from running. The changes ensure that complex tag parameters, including nested brackets and escaped characters, are now handled accurately, improving test reliability.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#261896 Forward-Port-Of: odoo/odoo#261516
This update fixes a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is now corrected to show only the date. This ensures consistency and accuracy in e-waybill documentation.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update resolves an issue where customers couldn't be found using their email addresses. The system was incorrectly searching for emails in the phone field. This change ensures accurate customer retrieval based on email, improving data accuracy and customer identification.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update corrects a technical issue that could cause problems with voice message tests. The fix ensures that asynchronous operations related to voice playback complete before resolving promises, preventing race conditions. This improves the stability and reliability of voice messaging functionality.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783 Forward-Port-Of: odoo/odoo#261910 Forward-Port-Of: odoo/odoo#261795
This update resolves a technical issue that could cause instability in voice message testing. The change ensures that asynchronous operations complete before promises are resolved, preventing race conditions and improving the reliability of our voice messaging functionality. This enhances the overall stability of the Odoo Enterprise platform.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/242411 Community: https://github.com/odoo/odoo/pull/261910 Forward-Port-Of: odoo/enterprise#115587
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly appearing in the Mod347 BOE export. The fix eliminates a redundant search process, ensuring that only relevant partners are included based on the primary data requirements. This improves the accuracy of the BOE export 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#114672 Forward-Port-Of: odoo/enterprise#110947
This update prevents unnecessary state resets for tasks that have been marked as done or canceled. Previously, changing a task's project would reset its state, even after completion. This change ensures tasks remain in their final state, streamlining workflow and reducing potential confusion.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
This update fixes an issue where quantities were incorrectly doubled when settling POS sales orders using the 'Pick then Deliver' warehouse method. The fix ensures accurate lot quantity tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order fulfillment.
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#261729 Forward-Port-Of: odoo/odoo#253539
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it in the main accounting view. Now, users can directly create and edit digipoort certificates within the accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115628 Forward-Port-Of: odoo/enterprise#114307
This update fixes a critical issue where gift cards and e-wallets could be reused after refunds, leading to potential misuse. Now, refunds completely disable the associated card or wallet, preventing fraud and ensuring accurate accounting. Additionally, the system now correctly handles products linked to multiple loyalty programs, allowing for distinct order lines.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#261647 Forward-Port-Of: odoo/odoo#256896
A technical error prevented importing emissions data through the ESG reporting tool. This update restricts imports to manual emissions, resolving the database conflict and ensuring accurate reporting. This change improves the reliability of our ESG data collection process.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587
This update corrects a technical issue preventing accurate stock availability calculations, specifically when using the MRP module. The change removes unnecessary restrictions on user permissions, ensuring the system correctly reflects stock levels across different user sessions (like POS).
Original PR description
Computing qty_available with sudo(False) drops superuser privileges, causing an AccessError on mrp.bom when the mrp module is installed. This happens because _compute_quantities_dict calls _bom_find, which performs an access check on mrp.bom that the current user (e.g. a POS session during online payment processing) may not pass. Removing sudo(False) preserves the calling environment's access rights, which is sufficient and avoids the permission error. opw-5975248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260755 Forward-Port-Of: odoo/odoo#252827
This update optimizes the process of preparing data for workcenter visualizations, resulting in significantly faster performance. By streamlining the check for workorders and pre-calculating resource calendar durations, the system now responds much quicker, especially with large datasets. This improves overall system responsiveness.
Original PR description
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching…
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching the field `order_ids` for all the workcenters. This can be too slow in cases where the workcenters have a lot of workorders and in addition to that there is no need to do this repeatedly for every workcenter. In this commit, I have modified the check by invoking a `search_count` on the workorders before iterating over the recordset and in addition to that I have pre-computed the sum of the duration hours of the attendances related to a `resource_calendar` as multiple workcenters might have the same `resource_calendar` The benchmark done below, was on a database that contained 78 workcenters. | Workorders | Before | After | | :--- | :--- | :--- | | 1380828 | 12s | 0.16s | | 138082 | 1.21s | 0.14s | | 13808 | 0.21s | 0.09s | opw-6040077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256812
This update fixes a problem where users without sufficient accounting permissions would encounter errors when retrieving information about components within purchase orders created by others. The change ensures that users with appropriate timesheet access can correctly access and analyze component data, improving data accuracy and workflow efficiency. This resolves a previous access restriction.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- *…
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989 Forward-Port-Of: odoo/odoo#261588 Forward-Port-Of: odoo/odoo#255824
This update stops invitations from being automatically sent when new people are added to events that have already occurred. This prevents unnecessary notifications and improves the user experience by only sending invitations for events that are currently happening or scheduled for the future. This was a previously reported issue (OPW-6125052) resolved by backporting a fix from the 19.0 release.
Original PR description
Backport of fix in 19.0 (https://github.com/odoo/odoo/pull/259844) Prevents invitations to be triggered when adding new attendees to an event in the past. OPW-6125052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261825 Forward-Port-Of: odoo/odoo#260050
This update fixes a slow performance issue that occurred when searching for stock quantities with a large number of items. The change ensures that Odoo respects the specified limit during these searches, dramatically reducing the time it takes to retrieve data. This improves the responsiveness of key features like picking and barcode operations.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update fixes an issue where invoices in multi-company branches weren't correctly calculating prices with taxes included. Previously, the unit price didn't adjust to exclude the original tax. This change ensures accurate pricing and tax calculations when using fiscal positions across different company branches.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#260840 Forward-Port-Of: odoo/odoo#256897
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies post-fix adjustments to the untaxed amount, aligning with standard tax rounding methods. This ensures accurate invoice processing and reporting related to UBL and CII standards.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260992