Wednesday, May 20, 2026
16 changes · saas-18.4
Enhancements to existing features
This update enables users to reset statement lines directly within the Kanban view, mirroring functionality from previous versions. Previously, this required manually deleting multiple reconciliations, which was inefficient. This change streamlines the process and improves user efficiency when managing statement lines.
Original PR description
This commit adds the possibility to reset a statement line in kanban view like in the previous versions. Function is still there but no UI button was tied to it. This is a problem if you have many reconciliations on one statement line, we do not want to delete them one by one. opw-6015838 Forward-Port-Of: odoo/enterprise#111107
Resolved issues and error corrections
The website editor now more reliably turns typed web addresses into clickable links when users press space. This fixes missed links with uppercase or mixed-case addresses and supports short domains like x.com or t.co.
Original PR description
### Description of the issue/feature this PR addresses: - URL_REGEX was constructed with the "i" flag, but passing a RegExp object to new RegExp(regex, "g") silently drops the original flags, leaving only "g". This caused uppercase (ODOO.COM) and mixed-case (Odoo.Com) URLs to not be converted to links when pressing space. ### Desired behavior after PR is merged: - URL_REGEX.source with explicit "gi" flags to preserve case-insensitive matching in `prepareConvertToLink`. - Allow automatic URL detection for single-character domains such as `x.com`, `t.co`, and `a.io` by relaxing the minimum domain label length in the URL regex from 2 to 1 characters. task-6199269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263255
This fix updates point of sale test helpers so they search for a customer before selecting them. This makes automated checks more reliable when customer lists are long and load progressively, helping prevent false test failures.
Original PR description
Make clickPartner search for the partner first to handle infinite scroll. Fixes: - test_preset_customer_selection - test_not_create_loyalty_card_expired_program - test_not_create_loyalty_card_max_usage_programm task-id: 5897380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246784
This fixes an issue in the HTML editor where selecting content starting inside a table cell and ending outside the table did not select the whole table as expected. Users now get consistent table selection behavior regardless of the direction they drag or select content.
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
The online shop now only shows a crossed-out comparison price when that comparison price is higher than the actual sale price. This avoids misleading shoppers when both prices are the same and keeps product search results consistent with product pages.
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#265004 Forward-Port-Of: odoo/odoo#262434
Website editors can now change colors on shaped images in the affected call-to-action and closer-look snippets. This fixes a missing editing option, making page customization more consistent and reducing manual workarounds.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905 Forward-Port-Of: odoo/odoo#246249
This update fixes a typo in the Mexican localization accounting group data so records better match the official SAT reference. It helps businesses using Mexico localization keep chart of accounts grouping information accurate for reporting and compliance workflows.
Original PR description
Source: https://www.sat.gob.mx/minisitio/NormatividadRMFyRGCE/documentos2026/rgce/anexos/Anexo24delasRGCEpara2026.pdf opw-6174385 Forward-Port-Of: odoo/odoo#262549
Service products now keep the unit of measure default chosen by the user instead of being unexpectedly changed to hours. Products billed through timesheets still use a time-based unit where required, preserving correct invoicing behavior.
Original PR description
A user-defined default on `product.template` Unit is not applied when the product is of type Service 1. Install Sales and Sales Timesheet 2. Go to Settings > Sales > Product Catalog and enable Units of Measure & Packagings 3. Enable debug mode 4. Go to Sales > Products, open a new product form and set unit to Days 5. In the debug menu (bug icon in the top right), select Set Default Values for Unit = Days and save 6. Reload the page 7. Set the type to Service 8. Unit changes from Days to Hours Same issue happens for `product.product` Issue: User default values are overwritten when certain conditions are met by https://github.com/odoo/odoo/blob/6955370fd2d62c83f0ea24247abf7a9e4b4ebed3/addons/sale_timesheet/models/product_template.py#L55-L57 Solution: Use the user defined default on `uom_id` except for service products that are invoiced with timesheets as they need a time unit of measure opw-6139603 Forward-Port-Of: odoo/odoo#262597
This fixes a display issue in selection pop-up windows where the controls and list headers could scroll away while browsing results. Users can now keep key actions and column labels visible, making it easier to select records in long lists.
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 Forward-Port-Of: odoo/odoo#264965
The website editor now only shows the eCommerce Categories mega menu option when there are published products to display. This prevents users from creating an empty mega menu that triggers an error when changing its layout.
Original PR description
Steps to reproduce: =================== 1. Create a product, link it to an eCommerce category, keep it unpublished. 2. Create a mega menu, edit it. 3. Enable "eCommerce Categories" and try to change…
Steps to reproduce:
===================
1. Create a product, link it to an eCommerce category, keep it unpublished.
2. Create a mega menu, edit it.
3. Enable "eCommerce Categories" and try to change the number of columns.
=> Mega menu is empty and a JS error is logged in the console.
Cause:
======
The "eCommerce Categories" toggle in the mega menu builder appears whenever any `product.public.category` exists for the website. Once toggled, the eCommerce mega menu templates (`s_mega_menu_multi_menus`, etc.) are server-rendered and the resulting HTML is stored on `website.menu.mega_menu_content`.
Since [1] , those templates filter their with
`('has_published_products', '=', True)`. So when the user has categories but no published product, enabling the toggle produces an empty `<div class="row"></div>`. Clicking the column-count option on that empty row which won't have any children and it will cause an error.
Solution:
=========
Adapt the toggle on the same condition the templates use, so it is only offered when there is at least one category that will actually be rendered.
[1]: https://github.com/odoo/odoo/commit/120a7633505891ba3e02e879f0c1a8287a690456
opw-6218503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents the replenishment action from crashing when a product's routes do not apply to the active company. Users can now continue replenishment without an error, improving reliability in multi-company stock setups.
Original PR description
## Steps to Reproduce: 1. Install the stock module. 2. Activate "Multi-Step Routes" from settings. 3. Activate the "My Company (Chicago)" company. 4. Create a route for the Chicago company. 5. Create a new product and enable the created route on it. 6. Click on the "Replenish" button. ## Error: `IndexError - tuple index out of range` ## Cause: At [1], when none of the product routes belong to the current company or are shared routes, the filtering returns an empty recordset. As a result, trying to access the first route from the empty result raises an index error. ## Fix: This commit only assigns `route_id` when a route matches the given condition. Otherwise, it keeps the value as `False`. [1] - https://github.com/odoo/odoo/blob/13c0e082c260381a332fe1425fe2ba83a1c0c579/addons/stock/wizard/product_replenish.py#L78 sentry-7488075413 Forward-Port-Of: odoo/odoo#265179
This update stabilizes an internal test for the HTML editor by removing timing assumptions that could fail on slower systems. It helps reduce false failures in automated checks, making releases more dependable without changing user-facing behavior.
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 Forward-Port-Of: odoo/odoo#264893
Studio report editing now avoids offering default website theme colors where they are not appropriate. This helps keep report formatting consistent and prevents users from selecting colors that may not work correctly in that editor.
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#265055 Forward-Port-Of: odoo/odoo#264917
This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to allow creators to successfully cancel their own approvals, streamlining the workflow and improving user experience.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104
This update fixes an issue where new WhatsApp channel members weren't correctly displayed as avatars in the sidebar. Now, avatars are pulled directly from the channel's WhatsApp member, ensuring users see the correct representation of each conversation. This improves the user experience and consistency within the WhatsApp channel.
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#117633 Forward-Port-Of: odoo/enterprise#115745
This update prevents the report editor in Odoo Studio from using default theme colors, which were causing potential styling conflicts. This change improves the consistency and reliability of report design within Studio, ensuring reports are rendered correctly regardless of the underlying interface customizations. This resolves a longstanding architectural issue.
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#117634
Forward-Port-Of: odoo/enterprise#117555