Daily updates from Odoo
Saturday, May 16, 2026
19 changes
4 changes
Resolved issues and error corrections
This update fixes an issue where demo data didn't correctly populate the 'Device Installation and Maintenance' worksheet for Field Service products. By loading product demo data, the system now automatically assigns the appropriate worksheet, ensuring demo data is accurately represented.
Original PR description
Load product_product_demo.xml in the 'planning_field_service_sale_worksheet' module so that the `Device Installation and Maintenance` worksheet is correctly set in Field Service product when demo data is loaded, instead of using the default worksheet. Forward-Port-Of: odoo/enterprise#117407
This update optimizes how Odoo handles boolean searches, specifically when searching for fields that can be True or False. By moving the optimization step earlier in the process, Odoo ensures compatibility with various search implementations, leading to more reliable and efficient search results. This change improves overall system performance.
Original PR description
When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264636This update addresses a potential instability issue during module upgrades. When an upgrade fails, a process is now initiated to reset the module's state and commit the changes before re-raising the error. This ensures a cleaner and more reliable upgrade experience for users.
Original PR description
If we fail to upgrade modules, we call `reset_module_state`, but this needs to be committed before re-raising the exception. Introduced in e6bcdfb92f1f0c39ec69d15d7c683d3f93573fa8. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error that prevented multiple expense bills from being paid correctly. The issue stemmed from incorrect data being passed during payment creation, specifically related to bank account information. This fix ensures that multiple expense bills can now be paid without errors.
Original PR description
**Steps to reproduce:** - Install Accounting and Expenses - Create an expense: * Category: [any] * Total: [any] * Employee: [create or select one without a bank account] * Paid by: Employee (to reimburse) - Submit - Post Journal Entries (in Purchases journal) - Create another expense, submit it and post its journal entries - Go to the bills list - Select both bills created from the expenses - Click on "Pay" and then on "Create Payments" **Issue:** A traceback is raised while creating a payment. **Cause:** In the values used to create the payment, "partner_bank_id" is an empty "res.partner.bank" recordset instead of False, which leads to a SQL error because the type of the value is invalid. opw-6206315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263841
6 changes
Resolved issues and error corrections
This update fixes an issue where activity type icons in the 'Schedule Activity' dialog and related views were consistently showing a generic checkmark instead of their correct Font Awesome icons. The fix ensures that each activity type displays its designated icon, improving the user experience and visual clarity.
Original PR description
**Problem:** In the "Schedule Activity" dialog and other views using the `selection_badge_icons` widget for many2one fields, every activity type badge renders the same check icon instead of its…
**Problem:**
In the "Schedule Activity" dialog and other views using the `selection_badge_icons` widget for many2one fields, every activity type badge renders the same check icon instead of its configured icon (envelope, phone, users, upload, warning, ...).
**Steps to reproduce:**
1. Open any record with a chatter (e.g. a Contact)
2. Click "Schedule Activity"
3. Observe the activity type selector **Current behavior:**
Every activity type shows `fa-check`.
**Expected behavior:**
Each activity type shows its configured icon from
`mail.activity.type.icon` (e.g. `fa-envelope` for Email, `fa-phone` for Call, ...).
**Cause of the issue:**
The many2one loader in `BadgeSelectionWithIconsField` (`selection_badge_icons`) was recently extended to support an optional icon mapping so a related-field value that is itself a selection key can be translated into an icon class (used e.g. by the homework location wizard: `home` -> `fa-home`). However, `iconMapping` defaults to `{}` via `defaultProps`, and the new branch was written as:
https://github.com/odoo/odoo/blob/7714b55eb9386d3cedd79d3ce4de7475b09af69a/addons/mail/static/src/views/fields/badge_selection_icons/badge_selection_icons_field.js#L52-L56
The empty default `{}` is truthy, so the code always takes the mapping branch. When no `icon_mapping` is configured in XML — the common case, since `mail.activity.type.icon` already stores raw Font Awesome classes like `fa-envelope` — the lookup `{}["fa-envelope"]` returns `undefined` and the final `|| defaultIcon` collapses every option to `fa-check`. This affects the activity schedule wizard, the activity form view, and the activity-related server action view.
**Fix:**
Looking up the mapping with optional chaining and falling back to `relatedFieldValue` keeps `icon_mapping` purely additive: when it is provided and contains the value, the mapped icon wins; when it is absent or does not contain the key, the related field value is used directly as the icon class. This preserves the selection-key mapping use case (homework location wizard) while restoring the raw-icon use case (activity types, server actions).
opw-6123405This update resolves a technical bug that could cause sorting issues within the Discuss channels feature. The fix ensures a consistent and reliable comparison of channel data, preventing potential infinite loops and improving overall stability. This change focuses on ensuring the sorting logic adheres to established anti-symmetry rules.
Original PR description
In order to work properly, a comparison function must be anti-symmetric, that is, if `compareFn(a, b)` gives `-1`, then `compareFn(b, a)` should give `1`. In the case of `sortChannels`, whenever `c1.displayName` is undefined, it falls back to comparing ids, but no such behavior is implemented when `c2.displayName` is missing, breaking the antisymmetry property. This flaw in the comparison function can potentially lead to infinite loops. This commit solves the issue, explicitly handling both `c1.displayName` and `c2.displayName`, in an antisymmetric fashion. Forward-Port-Of: odoo/odoo#264398
This update optimizes how Odoo handles boolean searches, specifically when searching for records where a field is either True or False. By moving the optimization step earlier in the process, Odoo ensures compatibility with various search implementations and improves overall search performance. This change primarily affects internal search functionality.
Original PR description
When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264636This update ensures that delivery slips now accurately display the packaging unit and quantity used for validated stock transfers. This change was triggered by a previous update and corrects a limitation where this information wasn't shown. It improves the clarity and accuracy of delivery reports.
Original PR description
This reverts commit efab5c52569d64e6d73cacf7611a40b025df52fb. `packaging_uom_id` only exists on `stock.move.line` once the stock_barcode module is installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264813 Forward-Port-Of: odoo/odoo#264746
This update eliminates a visual glitch where overlays (like Dialogs) sometimes appeared twice when initially displayed. The change improves the stability and user experience by preventing unnecessary re-renders of overlay containers, ensuring a smoother appearance.
Original PR description
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or…
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`. This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time. [1]: odoo#169264 [2]: odoo#154349 Forward-Port-Of: odoo/odoo#263860
This update corrects a bug where changes to cloned website snippets weren't properly reflected in the user interface. Now, when content in a duplicated snippet is modified, the UI will accurately display the updated state, ensuring consistency and preventing outdated information. This improves the reliability of the website editor.
Original PR description
Steps to reproduce: 1. Open the website editor 2. Add a snippet containing text content 3. Clone the snippet 4. Change the website language 5. Switch to translation mode 6. Modify the content of the original snippet => The cloned snippet reflects updates from the original snippet due to shared content, but is not marked as `o_dirty` and remains in a clean (yellow) state. Expected behavior: Cloned snippets should be marked as `o_dirty` when their content changes indirectly, ensuring the UI accurately reflects the modified state. This fix ensures duplicated snippets are flagged as `o_dirty` on indirect updates, preventing silent UI inconsistencies and improving state visibility. task-6176337 Forward-Port-Of: odoo/odoo#261916
5 changes
Resolved issues and error corrections
This update resolves an issue where Italian EDI bank account imports weren't automatically creating new bank accounts. The fix ensures that bank account records are now created and properly assigned to the corresponding customer, improving the accuracy of financial data. This change was driven by a test case related to simplified invoices.
Original PR description
The Italian EDI import didn't create new bank account by itself. IBAN info was just logged in the chatter, leaving it up for the accountant to create the bank account record. The bank account should be created and assigned to the corresponding commercial partner and set to not trusted yet. Enterprise PR: odoo/enterprise#112794 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/odoo#264382 Forward-Port-Of: odoo/odoo#254505
This update resolves a test failure related to importing partner and bank account data for Italian reporting. The team restored a specific data state within the test file, ensuring the tests now pass correctly. This prevents disruptions to the Italian reporting functionality.
Original PR description
The related PR brings a data change in a test file that is used here. We bring back the state of that data in the test class, so that the tests don't fail anymore. Community PR: odoo/odoo#254505 Task [link](https://www.odoo.com/odoo/project.task/6046189) task-6046189 Forward-Port-Of: odoo/enterprise#117275 Forward-Port-Of: odoo/enterprise#112794
This update optimizes how Odoo handles boolean searches, specifically when searching for fields that can be True or False. By moving the optimization step earlier in the process, the system now correctly handles a wider range of search implementations, leading to faster and more reliable search results. This change improves overall system performance and stability.
Original PR description
When optizing `('searchable_bool_field', 'in', [True, False])`, the optimization for the tautology is called after the search method. We should do it before as this case may not be handled by implementations which always expect `'in'/'not in', [True]`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#264636This update ensures that delivery slips now accurately display the packaging unit and quantity used for validated stock transfers. This change was reverted to align with a previous update and addresses a dependency on the stock_barcode module, which wasn't initially present. This improves the clarity and accuracy of delivery reports.
Original PR description
This reverts commit efab5c52569d64e6d73cacf7611a40b025df52fb. `packaging_uom_id` only exists on `stock.move.line` once the stock_barcode module is installed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264746
This update corrects a visual glitch where overlays (like Dialogs) sometimes appeared twice when initially displayed. The change improves the stability and user experience by preventing unnecessary re-renders of these overlays, ensuring a smoother display.
Original PR description
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or…
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`. This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time. [1]: odoo#169264 [2]: odoo#154349 Forward-Port-Of: odoo/odoo#263860
4 changes
Resolved issues and error corrections
This update resolves a technical problem preventing the Account Asset module from properly updating. The issue stemmed from an outdated process that caused database errors and prevented users from accessing the system. This fix ensures the module updates correctly and reliably.
Original PR description
This commit fixes the account asset error when updating the module. The problem was the `account.depreciation.model.csv` was being loaded again and if there was a `running` asset, it causes an error that we can't update a depreciation model that has running asset. As a result gets the module stuck in the to upgrade state which means that on every request to the Odoo db it will attempt the module upgrade again, which will keep failing, rendering the database inaccessible. Bug introduced in https://github.com/odoo/enterprise/pull/110143. A new condition in the write is added to make sure that the module is not in `install_mode` to bypass the update condition. opw-6216476 Forward-Port-Of: odoo/enterprise#117434
This update fixes an issue where completion and refusal emails for signatures were incorrectly using the partner's email address instead of the signer's email. Now, emails are sent using the correct, validated email address, ensuring signers receive important notifications accurately.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#117396 Forward-Port-Of: odoo/enterprise#114606
This update fixes a problem where demo data didn't correctly set the 'Device Installation and Maintenance' worksheet for Field Service products. Now, when demo data is loaded, the correct worksheet is automatically applied, ensuring accurate product information and setup.
Original PR description
Load product_product_demo.xml in the 'planning_field_service_sale_worksheet' module so that the `Device Installation and Maintenance` worksheet is correctly set in Field Service product when demo data is loaded, instead of using the default worksheet. Forward-Port-Of: odoo/enterprise#117407
This update resolves an issue where Discuss Avatar images weren't consistently displaying correctly across certain Odoo modules. The change standardizes how record properties are handled for DiscussAvatars, ensuring a more reliable and accurate display of avatars in the Enterprise suite. This improves the user experience for all users.
Original PR description
https://github.com/odoo/odoo/pull/264304