Daily updates from Odoo
Wednesday, June 3, 2026
230 changes
4 changes
Resolved issues and error corrections
This update resolves an issue where time off requests with the 'Both' approval type didn't send notifications to the designated responsible parties (e.g., Time Off Officer). The fix ensures that notifications are correctly triggered, improving the accuracy and efficiency of the time off request process. This prevents delays and ensures timely approvals.
Original PR description
…cer') no fallback for responsible_ids
Issue:
When ('both','By Employee's Approver and Time Off Officer') is selected on a new HR Leave Type it does not fall back to the responsible_ids or “Notify HR”.
Steps:
1) Setup a neutralized outgoing mail server
2) install hr_holidays
3) make a new hr.leave.Type (Approval) with ('both','By Employee's Approver and Time Off Officer') and select a 'Notified Time Off Officer'(responsible_ids) 4) select an emplyee with a reelated user and remove the coach, manager, and responsible 'Time Off'. 5) save
6) Sign in as the employee, make a time off request under the new Type 7) No email
Fix:
Add a conditional with the lowest priority to fall back to responsible_ids
opw-6101637
Forward-Port-Of: odoo/odoo#265760
Forward-Port-Of: odoo/odoo#261853This update resolves an issue where paying a PL supplier without a VAT number on invoices over 15,000 PLN would trigger an error. The fix adds a check to prevent unnecessary verification creation, improving the stability of the bank verification process for PL suppliers.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute. Forward-Port-Of: odoo/odoo#267888 Forward-Port-Of: odoo/odoo#266878
This update fixes an issue where EDI invoices were incorrectly assigned to individual contacts due to shared VAT numbers. The change prioritizes main companies and active vendors during matching, ensuring invoices are routed to the correct business entity. This improves data accuracy and reduces manual intervention in invoice processing.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share…
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor. **Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records. ### Current behavior before PR: When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback. ### Desired behavior after PR is merged: The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected. opw-6174628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266224
This update fixes a technical error in Odoo's internal tools that could cause a crash when copying data. The issue stemmed from how Python 3.14 handles weak references during copying, leading to a runtime error. The fix utilizes a more reliable method for copying the data, ensuring stability and preventing future disruptions.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
3 changes
Resolved issues and error corrections
This update fixes a previous limitation where channel owners without system admin privileges couldn't promote members to admin roles. The change ensures that channel owners can now correctly assign admin access, improving channel management capabilities. This resolves a usability issue for channel administrators.
Original PR description
`canSetAdmin` was checking the target member role instead of the current user's role. Because of that, a channel owner who was not a system admin could not promote another member to admin. task-6250058 Forward-Port-Of: odoo/odoo#266615
This update fixes an issue where EDI invoices were incorrectly assigned to individual contacts due to shared VAT numbers. The change prioritizes main companies and active vendors during matching, ensuring invoices are routed to the correct business entity. This improves data accuracy and reduces manual intervention in invoice processing.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share…
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor. **Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records. ### Current behavior before PR: When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback. ### Desired behavior after PR is merged: The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected. opw-6174628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266224
This update fixes a technical issue in Odoo related to Python 3.14's garbage collection. Specifically, it prevented a runtime error that occurred when copying data structures using an `OrderedSet`. The change utilizes a more reliable copying method to avoid conflicts with the garbage collector, ensuring data integrity.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
2 changes
Resolved issues and error corrections
This update corrects a technical issue where message authors were sometimes incorrectly identified. The change ensures that the correct user (partner or guest) is always used as the message author, improving the reliability of message attribution. This resolves a potential inconsistency in how message authorship is tracked.
Original PR description
A message's author is identified by one of two fields depending on its model: `author_id` (for partners) or `author_guest_id` (for guests). Previously in `changeThread`, the value of `thread.effectiveSelf` (which can be either a Partner or a Guest) was provided as the `author_id` regardless of its actual model. This commit explicitly uses `store.self_partner` as the `author_id` and `store.self_guest` as the `author_guest_id` to resolve the occasional mismatch. Forward-Port-Of: odoo/odoo#267464
This update ensures that activity labels in the Chatter interface always display the correct information, even when the default summary is removed. Previously, the system only stored the summary, leading to blank labels. Now, both the summary and display name are stored, guaranteeing accurate activity labels for users.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266706
2 changes
Resolved issues and error corrections
This update corrects a bug where changes to the provider state on the Ticket Screen didn't update order filters. The fix ensures that selecting a new state properly refreshes the screen and applies the correct filters, preventing outdated order information. This improves the accuracy of order review for UrbanPiper users.
Original PR description
Steps to Reproduce ------------------------- - Install Point of Sale and configure UrbanPiper. - Open a POS session and select a provider state from the notification popup to review orders. - While on the Ticket Screen, select a different provider state to review other orders. Issue ------- - Orders are not updated according to the newly selected state. - Previously applied filters remain unchanged. Cause -------- - Since the user is already on the Ticket Screen, changing only the provider state does not trigger a re-render. - The page was already rendered with the old filters. Fix ---- - The Ticket Screen is first switched away and then re-rendered. - This forces the screen to reload with the updated state and filters. Task: 6079663
This update fixes an issue where negative line items in the MX CFDI tax reporting were incorrectly distributed. The change is necessary due to new features added to the module. This ensures accurate tax calculations for Mexican businesses using the CFDI standard.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
2 changes
Resolved issues and error corrections
This update resolves a bug where users were unexpectedly locked out of list views after editing a row. The fix ensures the system correctly exits edit mode when a user clicks away, preventing the view from becoming unusable and restoring normal functionality. This improves user experience and data access.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#113000
This update fixes an issue where EDI invoices were incorrectly assigned to individual contacts due to shared VAT numbers. The change prioritizes main companies and active vendors during matching, ensuring invoices are routed to the correct business entity. This improves data accuracy for financial reporting and compliance.
Original PR description
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share…
### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor. **Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records. ### Current behavior before PR: When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback. ### Desired behavior after PR is merged: The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected. opw-6174628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266224
3 changes
Resolved issues and error corrections
This update resolves a bug where users were unexpectedly locked out of list views after attempting to edit a row. The fix ensures the system correctly exits edit mode when a user clicks away, preventing this frustrating interruption. This improves the overall user experience and data entry efficiency.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#113000
This update resolves a problem where users accessing archived documents through certain methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly displayed, improving the user experience when accessing older records. It's a follow-up to previous improvements related to document handling.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488 Forward-Port-Of: odoo/enterprise#117229
This update resolves an issue preventing accurate order data synchronization from Point of Sale (POS) systems. The fix corrects a typo and updates the system to correctly identify invoices as 'done' rather than 'invoiced', ensuring reliable data transfer. This improves the integration between POS and accounting systems.
Original PR description
In this commit: - Update `read_pos_data` to check `done` state for invoicing instead of `invoiced` state - Load `account.move` model instead of `account_move` (fix typo) Task-5887318
5 changes
New functionality added to Odoo
This update introduces the ability to print reports directly from Obox devices, mirroring functionality for IoT printers. The system now presents a popup allowing users to select a printer for each report, ensuring reports can be printed regardless of network connectivity. Currently, this implementation is simplified with limitations on printing multiple documents at once.
Original PR description
This commit adds report printing support for Obox printers, similarly to what already exists for IoT printers. A report can be linked to a printer, and then when printing a popup is shown to select from the linked printers. For now the implementation is intentionally simpler than the IoT equivalent, in the following ways: - Only one printer can be printed to at a time, not multiple. - The user cannot save preferences for which printer is selected, instead the popup to select a printer is shown every time. - There is no option to disable duplex (this will require an Obox change first). The print job uses a queue action so it does not rely on the user being on the same network as the Obox. task-6241709
Enhancements to existing features
This update refreshes the visual appearance of snippet thumbnails in the web editor, enhancing their design and clarity. The new thumbnails provide a more modern and intuitive representation of each snippet category, improving the overall user experience.
Original PR description
*: website_sale_renting This commit updates the snippet thumbnails in the web editor with new more modern designs. The updated thumbnails are more visually appealing and provide a clearer representation of each snippet category. task-5868664 Requires: - https://github.com/odoo/odoo/pull/246564
Resolved issues and error corrections
This update automatically fixes formatting issues in the Obox modules, ensuring consistent code style. The changes were made to improve code readability and maintainability, aligning with our development standards. This work is part of an automated process enforced by Odoo's linting system.
Original PR description
This commit fixes all Prettier formatting errors in the Obox modules. The lint check itself is enforced in odoo/odoo#267994.
This update optimizes the way Odoo calculates the display of work orders, specifically within the MRP module. By changing a selector used in the code, the system now recalculates styles more efficiently, leading to faster performance during common actions like resizing windows or scrolling through large tables.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior, this reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. Forward-Port-Of: odoo/enterprise#119024 Forward-Port-Of: odoo/enterprise#118618
A test was failing due to a limitation in how the POS system loads partner data. This fix ensures that all partners are properly searched for, resolving the test failure and improving the reliability of the point-of-sale tax functionality. This primarily impacts the US partner search functionality.
Original PR description
**Issue:** `test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983 Forward-Port-Of: odoo/enterprise#118345
2 changes
Resolved issues and error corrections
This update fixes a bug where online orders with 'tax included' products were incorrectly calculating prices. The fix ensures that the displayed unit price and tax-inclusive price accurately reflect the total cost of the product, including the applicable tax. This improves order accuracy for UrbanPiper integrations.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196
This update fixes a potential error that could occur when copying data within the Odoo tools module in Python 3.14. The fix ensures the copy operation is performed reliably, preventing a runtime error caused by the Python Garbage Collector. This improves the stability and reliability of the tools.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
7 changes
Resolved issues and error corrections
This update fixes an issue where vendor bills generated from Peppol/UBL XML files didn't automatically attach the embedded PDF. The fix ensures that the PDF is correctly extracted and included as an attachment when receiving UBL XML via email, improving the completeness of vendor bills.
Original PR description
When receiving a Peppol/UBL XML file containing an embedded PDF via an email alias, the PDF is not extracted and attached to the resulting vendor bill. Steps to reproduce: - Set up a BE Company - Configure an incoming mail server - Set up an email alias for the Vendor Bill journal - Receive a Peppol XML with embedded PDF via alias - Check the created Bill Issue: PDF has not been extracted from the xml This occurs because the received xml is set as main attachment for the record and in this case we skip extraction opw-6075250
This update addresses a performance bottleneck in Odoo's email processing, specifically related to how it searches for activity records. The previous method was slow and inefficient, leading to significant delays for regular users. This fix dramatically speeds up email operations by optimizing the record search process, resulting in faster response times.
Original PR description
Backport of v19 fix. In v17, _filter_records_for_message_operation accumulated records using the recordset |= operator, which copies and rebuilds the entire set on every iteration O(n²) total cost. On instances with many activity records not assigned to the current user, this caused response times exceeding 190 seconds for regular users while Administrator completed the same request in ~3 seconds (superuser bypasses the method entirely). Fix: Replace the recordset accumulator with a plain list and a single browse() per operation group, bringing the cost down to O(n). opw-6055334
This update addresses a slow performance issue in the Helpdesk ticket view for non-superusers. The previous method of filtering activities resulted in a significant delay (up to 2 minutes 18 seconds) due to an inefficient process. The fix replaces this with a faster method, reducing the load time to approximately 2.53 seconds, improving user experience and responsiveness.
Original PR description
Non-superusers loading a view filtered on `activity_ids` experienced severely degraded response times compared to Administrator, who bypasses the access control path entirely via an early `is_superuser()` return. Root cause: `_filter_records_for_message_operation` accumulated records using recordset |= which copies and rebuilds the entire _ids tuple on every iteration O(n²). Fix: Replace the accumulator with a plain list and a single browse() per operation group O(n). - With helpdesk.ticket list view, non-superuser, filter on `activity_ids = False` , number of tickets w/ activities not assigned to user : ~8812 : | Before | After | |:-------:|:------:| |~2m18s | ~2.53s | opw-6055334 Preceding PR -> https://github.com/odoo/odoo/pull/260147
This update resolves an issue where manually adjusted taxes on vendor bills generating COGS lines were incorrectly recalculated and reverted to the original values. The fix prevents taxes from being applied to COGS lines, ensuring accurate tax calculations for internal operations. This improves the reliability of financial reporting.
Original PR description
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This…
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them Steps to reproduce: 1. Turn on Anglo-Saxon accounting 2. Turn on automatic accounting 3. Make a FIFO product category and make the valuation automatic 4. Make a new product and set the FIFO product category on it 5. Make sure the product has a vendor tax set 6. Make a purchase order for 10 of the FIFO product category at $10 7. Create and validate the receipt for 10 8. Make a sales order for 6 of the FIFO product category at $10 9. Create and validate the delivery for 6 10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20 11. Edit the tax at the bottom of the total 12. Confirm the vendor bill 13. Notice that the tax at the bottom of the total changes 14. Reset the vendor bill 15. Remove the purchase tax from the product 16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time Cause: On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change Solution: Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids” opw-6110692
This update resolves an issue where spreadsheet formulas in the accounting module were sending incorrect data types to the server, leading to errors. Now, all company IDs are automatically converted to numbers, ensuring formulas work correctly regardless of the input format (string or number).
Original PR description
Current behavior before PR: - The `ODOO.CREDIT`, `ODOO.DEBIT`, and `ODOO.BALANCE` formulas passed `companyId.value` directly to the server without converting it to a number. - If a user passed company_id as a string (e.g., '1' from a cell), it was sent to the server as a string, causing a server error. Desired behavior after PR is merged: - `companyId` is converted using toNumber() before being passed to the getter and the server, so '1' becomes 1. - null is preserved as-is (no company filter) while any non-null value is safely cast to an integer. Task: [6240005](https://www.odoo.com/odoo/project/2328/tasks/6240005) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reverts a recent change that was disrupting the process of reconciling bank transactions with previous statements. It allows users to continue accurately matching current transactions with past records, ensuring correct financial reporting. This change addresses a workflow disruption impacting financial reconciliation.
Original PR description
This reverts commit e2a9f3bfbb8a89533146f76509bf2785c085ebea as it disrupt workflow where users needs to reconcile with a previous bank transaction Enterprise PR: https://github.com/odoo/enterprise/pull/118169 opw-6230807
This update addresses a technical bug related to how Odoo copies data using OrderedSets in Python 3.14. The fix ensures that the copy process is more stable by utilizing the dictionary's native copy method, preventing errors caused by the Python Garbage Collector. This improves the reliability of Odoo's internal data management.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy.