Tuesday, May 19, 2026
14 changes · saas-18.3
Resolved issues and error corrections
This update resolves a bug where users were incorrectly redirected after completing a signature request. The fix redirects users to their signature list within the portal, streamlining the process and preventing confusion. This ensures a smoother experience for users signing documents.
Original PR description
steps : - create a signature request with 2 roles, assign those to demo or portal user - create another one with a single signature role assigned to the demo or portal user - go on the portal and click on the second document to sign it - complete the document then click close on the thank you popup -> you are redirected on the portal view of the first document This happens because the redirect to /my/document is made using the sign_request id but the controller is using a sign_request_item id. Instead of adding a confusing controller route to be able to pass sign_request ids to reach the document's portal page, we simply redirect to the list of signatures on the portal instead. opw-6190390 Forward-Port-Of: odoo/enterprise#116949 Forward-Port-Of: odoo/enterprise#116600
This update resolves an issue where the Knowledge editor's printed output was excessively narrow on large screens. The fix specifically targets the CSS rule causing this problem, ensuring articles render correctly when printed or exported as PDFs. This improves the user experience for accessing and sharing knowledge content.
Original PR description
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size. See: ```scss .o_form_view.o_xxl_form_view { .o_form_view_container {…
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.
See:
```scss
.o_form_view.o_xxl_form_view {
.o_form_view_container {
width: 1px; /* List view needs a width value to recompute the size correctly */
}
}
```
However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.
Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"
=> The article is rendered in a very narrow column.
To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.
Task-5999878
Forward-Port-Of: odoo/enterprise#103259This update resolves a stability issue in the HTML Editor test by eliminating reliance on unpredictable timing mechanisms. The test now uses a more reliable method to verify the debounce functionality, ensuring consistent results across different environments and preventing test failures due to browser scheduling variations. This improves the overall reliability of our testing process.
Original PR description
Description of the issue this PR addresses: Previously the test relied on real timers, animation frames and simulateArrowKeyPress(), making it sensitive to browser scheduling, native selectionchange timing and CPU slowness. The test now: - use advanceTime() instead of real setTimeout() - Replace simulateArrowKeyPress() with manual selectionchange dispatch to make debounce scheduling deterministic and avoid relying on the browser's asynchronous native selectionchange dispatch. - Add patchWithCleanup + verifySteps to test actual debounce execution rather than DOM visibility timing, which is sensitive to rendering and brwoser scheduling variance. This removes timing races and stabilizes the test on slow CI workers. runbot-242466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where WhatsApp channel avatars were incorrectly displaying a default avatar instead of the member's actual avatar after a new member was added. Now, the sidebar correctly uses the WhatsApp channel member's avatar, ensuring a consistent and accurate representation of channel participants.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#115745
This update corrects a bug where portal users could inadvertently delete documents they didn't own through a specific archiving process. The fix ensures that portal users can only delete documents they own, preventing unintended data loss during automated trash collection. This improves data integrity and aligns with user permissions.
Original PR description
Reproduce: with rpc call as portal user, you can archive documents you have access to. This is not desired as this may lead to records being deleted when the cron collects the trash, but we only wanted to support portal users deleting only records they own. What we did when calling toggle_active should be done for all calls to `write` with `active`. It also removes the need for `_raise_if_unauthorized_archive` and `_unlink_except_unauthorized`. Task-6205627 Forward-Port-Of: odoo/enterprise#116886
This update resolves an issue where the Google address autocomplete field remained editable even in read-only views. The change ensures the field correctly displays its value when set to read-only, improving usability and preventing unintended data modifications. This fix enhances the stability and consistency of the Odoo application.
Original PR description
**Issue:** The `google_address_autocomplete` widget remained editable even when the view or field was set to `readonly`. **Solution:** Modified the `AddressAutoCompleteTemplate` to conditionally render the component. If `props.readonly` is true, the template now renders a `<span>` with the field value. Task~5182770 Forward-Port-Of: odoo/odoo#260952
This update resolves a visual glitch in the SelectCreateDialog, ensuring the control panel and list headers remain visible. The issue stemmed from a previous change that removed a key styling rule, and this fix re-applies it to restore the intended layout and functionality.
Original PR description
This commit fixes an issue where the SelectCreateDialog's control panel and list headers would scroll out of view, restoring the intended behavior introduced in https://github.com/odoo/odoo/pull/206433. The feature was inadvertently broken by https://github.com/odoo/odoo/pull/219972, which removed the `overflow: auto` rule from `o_content` elements outside of actions. To resolve this, the `overflow: auto` rule has been explicitly reapplied to the SelectCreateDialog content area. task-6214232
This update fixes an issue where embedded action names weren't consistently translated, leading to untranslated labels in areas like the Documents top bar. By delegating the display name to the linked server action, the embedded action's name will always reflect the correct, translated version. This ensures a better user experience with accurate action labels.
Original PR description
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the…
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language. This has a few issues: - When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name. - When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name. The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten. To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated. Related: https://github.com/odoo/enterprise/pull/116369 Forward-Port-Of: odoo/odoo#262981
This update removes a redundant step in creating embedded actions within Odoo. Previously, a separate translation process was required; now that embedded actions inherit their display names directly, the manual translation copy is no longer necessary, streamlining the process.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#116369
This update fixes a bug where the HTML editor wouldn't correctly select tables when a user started a selection within a table cell and then moved the selection outside of that cell. Previously, the entire table was selected in this scenario. This change ensures a more intuitive and reliable table selection experience for users.
Original PR description
The previous commit fixes a behavior that is expected when the user makes a selection that starts in any element and ends in a table cell (the whole table gets selected), but the reverse case was never handled, namely when the selection starts in a table cell and ends outside of it. backport-https://github.com/odoo/odoo/pull/239270/changes/68e71fad5bbb0445bb1850bf694235f3235b602f task-5420366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264947 Forward-Port-Of: odoo/odoo#264722
This update ensures that the price comparison strikethrough is only displayed on products when the compare price is higher than the regular sales price. Previously, it incorrectly showed a strikethrough even when the prices were identical, creating a confusing user experience. This change improves the accuracy and clarity of product pricing on the website.
Original PR description
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for…
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for the product. Issue: --- - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: --- - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: --- - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. Before: --- <img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" /> After: --- <img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" /> [1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264912 Forward-Port-Of: odoo/odoo#262434
This update fixes an issue where the Studio report editor was unintentionally using the system's default theme colors. The change prevents the editor from applying these colors, ensuring reports consistently use the intended design. This improves the visual accuracy and predictability of reports created within the Studio environment.
Original PR description
This commit will add a new props to ColorSelector to disable default theme colors to allows studio to not use them opw-6167143 linked to https://github.com/odoo/enterprise/pull/109206 enterprise https://github.com/odoo/enterprise/pull/117555 Forward-Port-Of: odoo/odoo#264917
This update prevents the report editor in Odoo Studio from using default theme colors, which were causing potential styling conflicts. This change ensures reports are styled consistently and independently of the main Odoo interface customizations. This resolves an underlying architectural issue identified in the core Odoo codebase.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style
to be influenced by the presence or lack thereof of the html_editor
module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143
community: https://github.com/odoo/odoo/pull/264917
Forward-Port-Of: odoo/enterprise#117555Documentation and clarification updates
This pull request implements a Corporate Legal Agreement (CLA) for QoQa, ensuring compliance with Odoo's contribution guidelines. The change was backported from version 18.0 to meet QoQa's requirements. This update primarily addresses a legal matter.
Original PR description
Description of the issue/feature this PR addresses: This is the corporate CLA for QoQa. I backported #262581 because we need it from 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262582