Tuesday, June 2, 2026
10 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where product variant prices didn't automatically update when the cost price was modified. Previously, users had to manually switch price lists to trigger the update. The fix ensures that changes to the cost price immediately reflect in the on-sale price, streamlining the pricing process.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and back to the one you want for it to trigger change because the _onchange_compute_pricing only gets triggered if there's change on pricelist (pricer_sale_pricelist_id), and sales price (lst_price). Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" doesn't update. 4.You have to change the price list to some other and back to the one you want for the "On Sale Price" to update. To fix the issue, we add the field Cost (standard_price) on api.onchange, so when we change the cost it'll update the "On Sale Price" right away. opw-5947995 Forward-Port-Of: odoo/enterprise#111892
This update fixes an issue where the Table of Contents in the HTML editor wasn't updating properly after editing headings. Specifically, deleting a heading caused the ToC to stop updating. The fix ensures the ToC is always refreshed when a heading is present, regardless of other edits.
Original PR description
Steps to Reproduce : - Go to To-Do → Create New and add a Table of Content block - Type text → in new line create /h1 → it appears in ToC - Place cursor before /h1 and press Backspace → it merges with paragraph Description of the issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 Forward-Port-Of: odoo/odoo#264161 Forward-Port-Of: odoo/odoo#261675
This update fixes an issue where users couldn't reliably select formatted text within a table cell. The change simplifies the selection process by directly verifying cell boundaries, ensuring consistent and accurate cell selection within the HTML editor. This improves the overall user experience when working with tables.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263742
This fix ensures that calendar event durations displayed in the full form accurately reflect the user's changes made in the quick-create popover. Previously, the duration was stuck with the original drag value, leading to incorrect event times. Now, the full form displays the updated duration after the user adjusts the event's end time.
Original PR description
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the…
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop. calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context. https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19 duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field. Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration. Steps to reproduce: 1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00) 2. In the quick-create popover, change the end time to 14:00 3. Click "More Options" 4. Check the Duration field in the full form => Duration shows the original drag value (02:00) instead of 04:00 opw-6087449 Forward-Port-Of: odoo/odoo#257294
A test related to the Point of Sale (POS) tax feature was failing due to a limitation in how the system loads partner data. This update corrects the test to ensure proper functionality when searching for partners, particularly in demo environments. This resolves a technical issue preventing the POS tax feature from working correctly.
Original PR description
**Issue:** "test_pos_fiscal_position_without_pos_avatax" test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983 Backport of https://github.com/odoo/enterprise/commit/968799612ff3a9cbba0ffbf4e644d6699abcfa81
This update ensures that email backgrounds remain consistent with the selected theme color, even after website palette changes. Previously, reopening a sent email would display the latest palette color, regardless of the original design. This fix guarantees that email designs accurately reflect the intended theme.
Original PR description
When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the…
When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`. `classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds. Steps to reproduce: 1. Open Email Marketing and create a new mailing using the Welcome Message template 2. Select a content block, open Customize, set the background to the 5th theme color 3. Save the mailing 4. Open the Website editor and change the 5th primary color to a different value 5. Reopen the saved mailing in the backend => the block's rendered background follows the new website color instead of the one picked at design time Ticket [link](https://www.odoo.com/odoo/project.task/5892350) opw-5892350 Forward-Port-Of: odoo/odoo#253934
This update fixes an issue where the payment link wizard copy button on mobile devices would appear partially hidden due to its long label. The change ensures the button fits properly within the screen width, improving the user experience on smaller devices.
Original PR description
Description of the issue/feature this PR addresses: The payment link wizard copy button can overflow horizontally on small screens because of its long label. Current behavior before PR: On mobile view, the copy button may appear partially hidden. Desired behavior after PR is merged: The payment link wizard copy button properly fits within the available width on mobile view. Before: <img width="514" height="667" alt="image" src="https://github.com/user-attachments/assets/9060bf5a-9590-47a6-b322-220ed0a871be" /> After: <img width="514" height="667" alt="image" src="https://github.com/user-attachments/assets/3b257e73-3744-4236-b28c-bad1a46ca92d" /> @Tecnativa TT58871 @CarlosRoca13 please review --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266303
This update clarifies the reporting of employee hours by renaming a confusing column from "Expected Hours" and "Theoretical Hours" to "regular hours". This change ensures that users clearly understand the data being presented, which is the actual hours an employee is scheduled to work.
Original PR description
The column name "Expected Hours" and "Theoretical Hours" is confusing since it doesn't show the hours that the employee is supposed to work according to their contract, just the number of hours that are not considered overtime. This commit renames the column to better reflect the measure that is shown. task-6123642 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 Forward-Port-Of: odoo/odoo#262230
This update resolves a technical issue preventing the Instagram snippet from loading correctly in iOS Chrome browsers. The problem stemmed from a change in how Chrome on iOS sends data, requiring a simple adjustment to our code to handle the data format. This ensures the Instagram snippet functions as expected for all users.
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#267027
Forward-Port-Of: odoo/odoo#254664This update ensures that errors related to intrastat codes are only triggered when creating product templates with dynamic attributes and no variants. Previously, the system incorrectly flagged this scenario, preventing users from setting intrastat codes. This change improves data accuracy and simplifies the product setup process.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986