Friday, May 29, 2026
8 changes · saas-18.2
Enhancements to existing features
Analytic Reporting can now group entries by the product category linked to each line. This makes it easier for finance and business teams to compare costs and revenues across product categories without extra manual filtering or exports.
Original PR description
Add the related (non-stored) 'product_category' field on the account.analytic.line model to make it available in the Analytic Reporting "Group By" task-6219418 Forward-Port-Of: odoo/odoo#266378
Resolved issues and error corrections
This fix prevents error messages from appearing when visitors view pages with the Instagram Page snippet in Chrome on iOS. It improves the browsing experience for internal users and debug sessions by safely ignoring unexpected browser messages that are not relevant to the Instagram embed.
Original PR description
Scenario:
- insert Instagram Page snippet
- using iOS chrome browser (reproduced in iOS 26.3, google chrome 146)
visit that page logged in as a internal user or in ?debug=assets (so
traceback are shown)
Result: 3 tracebacks errors are shown with error "Uncaught Promise >
JSON Parse error: Unexpeced identifier "object".
Cause: probably since this change:
https://chromium.googlesource.com/chromium/src/+/9629a16a7ab0b91c59ecaa9fc8934db3d6c83ba3%5E%21/
chrome on iOS is sending message with this object as data:
{ "command": "registerAsChildFrameAck", "remoteFrameId": "d905013d…" }
but the instagram code is expecting a stringified JSON.
Fix: ignore message data that are object.
opw-5930717
Forward-Port-Of: odoo/odoo#254664This update prevents an internal mail test helper from crashing when expected message data is absent. It improves reliability for automated checks, helping reduce false test failures without changing user-facing behavior.
Original PR description
This changes https://github.com/odoo/odoo/pull/230766/changes cause the issue. I fix `AttributeError` when `mail_message` is None in `assertNoMail` method. The method was accessing `mail_message.message_id `without checking if `mail_message` is `None` first, causing a potential crash in test cases. Added a conditional check to safely handle None values before accessing the message_id attribute. @qrtl Forward-Port-Of: odoo/odoo#255720
This fixes an issue in the HTML editor where bold, italic, or underline formatting could not be removed when a selection included inline code. Users can now reliably toggle formatting on and off in mixed text selections, improving editing consistency in apps that use the editor.
Original PR description
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching…
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching `is_formattable_node_predicates` are ignored. However, when checking whether the selection is already formatted, those nodes are not ignored, so the selection is erroneously considered to be only partially formatted. Solution: Take `is_formattable_node_predicates` into account when checking whether a selection is formatted. Steps to reproduce: - Go to To-Do → Create New. - Type some text and add inline code on the same line. - Select all content using Ctrl + A. - Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U). - Press the same shortcut again to remove the formatting. - Observe that the formatting is not removed. task-6229228 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265183
Live chat visitors will no longer see mention suggestions when typing @, removing options that were not useful in visitor conversations. Operators and internal users can still use mentions as before, so team workflows are unchanged.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253551
This update resolves an issue where marking workorders as done would trigger a traceback when no workorders were present. The fix ensures the system handles empty recordsets gracefully, preventing errors and improving stability. This ensures consistent operation regardless of the number of workorders in a given situation.
Original PR description
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety…
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 Inside button_finish, it retrieves all open workorders and marks them as done: - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 - mark them as done: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678 Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 -> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback. opw-6239910 Forward-Port-Of: odoo/enterprise#118403
This update resolves a bug where cancelled journal entries were incorrectly displayed in the reconciliation view, preventing successful reconciliation and leaving records unresolved. The fix removes a previous refactor that inadvertently allowed cancelled entries to appear, ensuring reconciliation processes function correctly.
Original PR description
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused…
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view. This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain: Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view. Also, we are not allowed to reconcile cancelled move lines, and we already have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627) Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing - OPW: 6247870
This update optimizes the process of determining user permissions for documents, resulting in faster performance. The change was a backport of a previous improvement, enhancing the overall responsiveness of the documents module. This translates to a smoother user experience when working with documents.
Original PR description
This commit is a backport of the improvement introduced in the following commit 706ee0c68c774f01b76802fe513aec52df16678c. Forward-Port-Of: odoo/enterprise#103850