Tuesday, March 10, 2026
19 changes · 19.0
Enhancements to existing features
Users can now find the Separator command in the editor powerbox by searching for “divider” or “line.” This makes it quicker to add visual breaks in content without needing to know the exact command name.
Original PR description
#### Desired behavior after PR is merged: - Separator command now appears when searching for “divider” or “line” in the powerbox. task-5977288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Return button on delivery and receipt records is now hidden until the operation is completed or linked to a sales or purchase order. This prevents users from seeing an action too early and avoids confusing warning messages during replacement flows.
Original PR description
_*= sale_stock, purchase_stock Steps to Reproduce: - Create a Helpdesk ticket. - Click Replace, and the picking form opens. - Add product lines to the picking to deliver to the customer. - Observe that the Return button is visible and shows a warning when clicked, even though the picking is not in Done state. Cause: - When `stock_account` is installed, the Return button visibility is overridden to always show (`invisible=0`), ignoring the original condition (`state != 'done'`). Solution: - Restore the Return button visibility to its original condition so it’s only shown when the picking is Done or when picking is linked to any PO or SO. task-5075584 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update removes a leftover internal reference in the HTML editor that was no longer used. It helps keep the editor code cleaner and reduces maintenance overhead, with no expected change for users.
Original PR description
The resource named `clean_handlers` should have been removed since [1], but a single occurrence has been forgotten and survived in `SeparatorPlugin`. This commit removes it. [1]: https://github.com/odoo/odoo/commit/3cd28b1972e704c54e5b40226bfbe4e0895481d8 task-5363816 Forward-Port-Of: odoo/odoo#247226
When a user creates a missing website page from the menu editor, Odoo now updates the menu link to match the final URL created by the server. This prevents menus and redirects from pointing to an invalid or outdated page address when special characters are cleaned from the URL.
Original PR description
The "Create Page" button was added in edit menu dialog in commit 990b7c045bf27280c64433510d6e43fba5b3a4b0. The button creates a page using the link in the menu for the url of the page, but the actual page creation may use a different url (as it slugifies it). This commit uses the url returned by the server on page creation to update the url of the menu, and correctly redirect to the new page. Steps to reproduce: - In edit menu > menu item, create a menu with url `/abc,xyz` - In edit menu, click "Create Page" - The page is created with a url that is slugified - Bug: but the menu does not use the slugified new url, and the url to which we redirect is not that one either task-5895401
Taiwan ECPay processing now uses the company's fiscal country instead of its physical address to decide when Taiwan-specific logic applies. This helps businesses using Taiwan tax localization get the correct ECPay behavior even if their registered company address is outside Taiwan.
Original PR description
Previously, the module checked `company_id.country_id.code == 'TW'` to determine if Taiwan's ECPay logic should be applied. However, `country_id` only represents the physical address of the company. This commit replaces `country_id` with `account_fiscal_country_id` across the sale order model and website controllers. This ensures that the ECPay integration correctly triggers for any company using the Taiwan fiscal localization. Task-6002433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252373 Forward-Port-Of: odoo/odoo#251924
The website configurator now highlights matching industries regardless of letter case, so user input with capital letters is recognized correctly. Synonym matching is also more accurate for multi-word terms, making industry suggestions easier to understand and select.
Original PR description
The industry highlighting to indicate what the user wrote match with the proposed industries was case sensitive, so the capital letters were not indicated as matching with lowercase letters. Fix: Added the flag "i" at the end of the regex to make it case-insensitive Also, in the case of the synonyms, the regex used was spliting on ",", "|" and space. The space spliting made matching a synonym sentence much more complicated. Fix: Deleted the space in the regex task-5066428
This fixes an issue where internal class-level methods appeared in API documentation even though they could not be called remotely. Business users benefit from clearer API documentation and fewer failed integration calls caused by misleading method listings.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Odoo from making external lookup calls or sending emails while demo data is being installed on an existing database. It reduces unintended side effects during setup or testing, helping keep demo installations quieter and safer.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid making api calls, sending emails when installing demo data on an existing database
The ecommerce product page now displays the price per unit when using the boxed layout, matching the behavior of other product page layouts. This helps customers compare prices accurately and keeps the shopping experience consistent.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prStudio's report editor no longer offers default theme colors that are meant for website/interface editing rather than reports. This helps keep report styling consistent and prevents reports from depending on optional editor-specific color definitions.
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…
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. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Razorpay payments no longer fail when a customer's name contains a comma or is longer than Razorpay allows. The system now adjusts the name before sending it to Razorpay, helping more customers complete checkout successfully.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay. Forward-Port-Of: odoo/odoo#252444
The editor now keeps manually selected outline button colors exactly as chosen, instead of automatically adjusting them for contrast. This makes buttons styled through the Theme tab look more predictable and consistent with standard buttons.
Original PR description
Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies…
Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies with standard `btn`. This commit fixes that by providing the contrast-adjusted color only on default palettes, and use the manual color as is when selected in the Theme tab. task-5392258 | State | Before | After | |--------|--------|--------| | Normal | <img width="261" height="122" alt="image" src="https://github.com/user-attachments/assets/482ed97f-303c-4332-a748-1130a9ee5db7" /> | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/5e0b14ba-677a-480e-8aad-85c13f3a5f6e" /> | | Hover | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/87cec4fc-521c-4b36-84d3-81460cefa68c" /> | <img width="259" height="123" alt="image" src="https://github.com/user-attachments/assets/b17c309d-2b64-4dc2-a33b-e576831647e0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures stock availability email tests use a website partner with an email address. It also prevents fallback to the current user's email, so missing sender details are caught instead of silently sending from the wrong address.
Original PR description
This commit (https://github.com/odoo/odoo/pull/249299/changes) backported some changes concerning stock availability mails. The mail is now sent from the partner associated to the website. However, in nightly runbots, the partner associated to the website does not have any email, so an error is thrown This fix does two things : - Make sure the website's partner has an email when running the tests - Prevent the mails being sent with the current user's email as a last ressort, and let an error be thrown instead runbot-102934954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252546 Forward-Port-Of: odoo/odoo#251951
Opportunity meeting dates now use the user’s configured time zone when shown on the CRM smart button. This prevents late-day meetings from appearing as the wrong calendar day, reducing scheduling confusion for sales teams.
Original PR description
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) -…
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) - Go to the form view of an opportunity - Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity) - In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00) - Go back to the opportunity for view # The problem The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11 # Why The calendar view uses the browser's timezone to manage the dates. The smart button does not. It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly. The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences. opw-5898520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251840 Forward-Port-Of: odoo/odoo#247984
This update corrects self-order tests so products are marked as available in the point of sale when needed. It helps prevent test failures caused by products not appearing in the self-ordering interface, improving reliability without changing customer-facing behavior.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forwarded vendor bills are now handled more accurately when the message body includes the company's own email address. This prevents the system from mistakenly assigning the company itself as the vendor, reducing manual correction and accounting errors.
Original PR description
Prevent setting the company's partner as the vendor for a forwarded bill when the body contains the company's email.
This update fixes an issue where the 'Today' button in the Gantt view didn't reliably return to the current date after navigating from yesterday. The fix ensures the button functions as expected, providing a consistent user experience when viewing schedules.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update resolves an issue where the Odoo Report Editor was unintentionally influenced by default theme colors, leading to potential styling inconsistencies. By preventing the report editor from using these theme colors, we've improved the stability and predictability of report designs. This change ensures reports consistently render as intended.
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
opw-5892573A previous shortcut in the asset management module was causing users to navigate to the wrong view instead of the previous asset. This update corrects this behavior by changing the shortcut to ALT + SHIFT + P, aligning it with other similar shortcuts within Odoo.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022