Tuesday, June 2, 2026
16 changes · saas-18.4
Resolved issues and error corrections
The WIP report now leaves product and reference details blank when they are not set on an analytic item, instead of showing sample demo values. This prevents users from seeing misleading product or reference information while keeping demo data available only in the report editor preview.
Original PR description
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to…
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to settings and Enable Analytic Accounting - Search Analytic items and create a new Analytic Item by providing a description and amount. - Gear Icon > print and open the WIP report ## Observed Behavior: The report displays a product (laptop) with a demo reference. This becomes problematic when an analytic item is tracked only with a project, as it still causes product and reference data to appear on the analytic item. This can mislead the user. ## Root cause: After this [commit](https://github.com/odoo/odoo/commit/967ac550e38bab915180647dea6eccb2ae1b3b31), demo data values were added to the report to support report editor previews in the web studio. This helps users understand how the report will look while they are editing it. However, although an account analytic line is defined at [1], no values for fields such as products and references are specified on the form. As a result, the template falls back to the preview values provided. [1]- https://github.com/odoo/odoo/blob/d66bb0d7b550b11876dbc7b9d87f5b2adc17dd74/addons/mrp_account/report/report_mrp_templates.xml#L32-L53 ## Solution: Using `data-oe-demo` instead of removing the fallback data appears to be the best approach, as it allows the report editor to continue using demo values for the report preview, as shown at [2] **Before:** <img width="871" height="340" alt="image" src="https://github.com/user-attachments/assets/91897dbd-65d8-4f70-8f22-ea38b42ba28d" /> **After:** <img width="815" height="380" alt="image" src="https://github.com/user-attachments/assets/ffcf509b-f534-47a8-be1d-53a798995443" /> [2]: https://github.com/odoo/enterprise/blob/a739c6c03c6629bad80f3fe61b1035ce156d59c6/web_studio/static/src/client_action/report_editor/report_iframe.scss#L65-L75 opw-6151563 Forward-Port-Of: odoo/odoo#262517
This fixes an issue in the HTML editor where users could not select a single table cell after applying formatting such as bold or italic. The change makes table editing more reliable and prevents frustration when formatting or adjusting individual cells.
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
Fixed an issue where a table of contents could show outdated entries after a heading was merged back into regular text. This keeps document navigation accurate for users editing notes or pages.
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
Portal users now see invoices sorted by the displayed payment status, such as Paid, Not Paid, or In Payment. This prevents confusion caused by sorting on a different internal invoice state and makes invoice lists easier to review.
Original PR description
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. -…
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. - Navigate to the invoices list and attempt to sort by **Status**. Issue:- --- - Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering. Root cause: --- - At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state. Fix: --- - Update the sorting configuration to use payment_state instead of state, ensuring that invoices are sorted correctly according to their payment status on the portal. [1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52 opw-6128998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262976
Calendar events now keep the updated duration when users move from quick create to the full event form. This prevents confusion where the detailed form showed the original dragged time span instead of the end time the user had just selected.
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
Currency amounts in Accounting now keep the minus sign and currency symbol in the correct order when viewed in right-to-left languages such as Arabic. This prevents misleading payment amounts on dashboards and related accounting views.
Original PR description
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the…
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount 4. Switch the user language to Arabic 5. Open the Accounting dashboard Issue The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252 opw-6183749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266742
This fixes a display issue where chatter activities could appear without a title when their summary was empty. The activity label is now stored and shown as a fallback, helping users identify activities more reliably.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266706
Website visitors in livechat will no longer see @ mention suggestions, since those suggestions were limited to themselves or OdooBot and did not add value. Internal livechat operators can still use mentions as before, keeping staff workflows unchanged while reducing noise for customers.
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#267219 Forward-Port-Of: odoo/odoo#253551
Closing the website attribute translation dialog now leaves unsaved edits unapplied unless the user confirms them. This prevents accidental translation changes and avoids creating unnecessary edit history when nothing changed.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459
The payment link wizard's copy button has been adjusted so it no longer gets cut off on small screens. This makes it easier for users to copy payment links from mobile devices without layout issues.
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
The attendance report now uses the label "Regular Hours" instead of confusing terms like "Expected Hours" or "Theoretical Hours". This makes it clearer that the value represents non-overtime hours, not the employee's contracted working hours.
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
The website Instagram Page snippet no longer shows error tracebacks for internal users or debug sessions when opened in Chrome on iOS. The fix ignores unexpected browser messages so visitors and editors get a cleaner, uninterrupted page experience.
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 resolves an issue where product variant prices weren't automatically updating when the cost price changed. Previously, users had to manually switch price lists to trigger the update. The fix adds a direct update mechanism to ensure on-sale prices accurately reflect cost changes, improving pricing accuracy and reducing manual intervention.
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
A technical issue preventing users from accessing billing targets in the Timesheets module has been fixed. This change ensures the billing process functions correctly for employees, particularly when 'Billing Rate Indicators' are enabled and specific user access settings are in place. The fix involved adding a necessary field to resolve a dependency conflict.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value.
This update corrects a bug where paying with the 'customer account' payment method on a zero-priced order resulted in an incorrect 'change' calculation. The fix hides the 'pay_later' payment option in this scenario, aligning with business process requirements and preventing incorrect accounting.
Original PR description
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any…
Step to reproduce: - install "pos_settle_due" - create a pos order, set order price = 0, select a customer - go to payment page, select "customer account" as payment method - here you can set any amount to pay, ex 100$ - fulfill the order. Observation: - the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer) - As per PO, this flow doesn't make sense Issue: - customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] - [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35 Fix: - we hide payment method of type "pay_later" in case of 0 price order opw-6123699 Forward-Port-Of: odoo/enterprise#118093 Forward-Port-Of: odoo/enterprise#116556
A test was failing in our Point of Sale (POS) tax feature 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 the US, and prevents disruptions to the POS experience. This resolves a previous issue impacting the AvaTax integration.
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 Forward-Port-Of: odoo/enterprise#119069