Wednesday, September 23, 2026
12 changes · saas-19.3
Resolved issues and error corrections
Delivery slips now show clean, properly rounded quantities when stock moves are split across multiple lines. This prevents confusing decimal artifacts from appearing on customer-facing warehouse documents.
Original PR description
**Issue** When a move has several move lines, the printed quantities are not rounded, causing floating-point arithmetic artifacts to appear on the report. **Steps to reproduce** - Create and confirm…
**Issue** When a move has several move lines, the printed quantities are not rounded, causing floating-point arithmetic artifacts to appear on the report. **Steps to reproduce** - Create and confirm a PO for 15.6 units of a product. - On the receipt, change the quantity to 17.8 (this splits it into two stock move lines). - Validate the receipt and print the delivery slip. -> The ordered quantity on the generated PDF is not rounded (floating-point arithmetic issue). **Cause** While printing the delivery slip, quantities are aggregated by product: https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/report/report_deliveryslip.xml#L174 No rounding is performed while subtracting quantities from the ordered quantity (resulting in 13.399..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L927 Nor while adding the second move line's quantity back to the ordered quantity (resulting in 15.599..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L938 **Additional note** Same issues arise for `packaging_qty_ordered`, `quantity` and `packaging_quantity`. opw-6469422 Forward-Port-Of: odoo/odoo#286846 Forward-Port-Of: odoo/odoo#283792
The website project form processing has been cleaned up to make submissions more reliable and easier to maintain. This prepares the form workflow for future updates while keeping the user-facing behavior stable.
Original PR description
Clean up and move some of the form processing logic for future updates opw-6560036 Forward-Port-Of: odoo/odoo#287697
This fixes an HTML editor toolbar issue where the font size field could show an outdated value after a user removed formatting from selected text. It also improves handling of default heading and font size styles, reducing confusing toolbar states and preventing unnecessary nested formatting when users apply a new font size.
Original PR description
### Steps To Reproduce: - Add this content in the HTML editor: `<h2 class=display-3-fs>heading 2</h2>` - Select the heading text. - Click Remove Format. - Check the font-size input in the toolbar.…
### Steps To Reproduce: - Add this content in the HTML editor: `<h2 class=display-3-fs>heading 2</h2>` - Select the heading text. - Click Remove Format. - Check the font-size input in the toolbar. ### Description of the issue/feature this PR addresses: - The font-size class was removed from the block element, but the font-size input still displayed the value associated with the removed class. - The toolbar did not show the correct font size for default block classes (like `o_default_font_size`). - Applying a new font size inside default block classes created nested spans instead of splitting them. - The "Remove format" button remained enabled even when selection had no custom formatting (only default block classes). ### Desired behavior after PR is merged: - The font-size input is updated after removing the font-size class and correctly displays the font size of the resulting block element. - Update the `getFontSizeDisplayValue` utility to find correct CSS variable dynamically to also find the font size of default block classes. - Add default font size classes (like `o_default_font_size` and headings) to `format_class_predicates` resource in `font_plugin.js`. This allows them to be split and replaced instead of creating nested spans. task-6321166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289232 Forward-Port-Of: odoo/odoo#272023
This fix stops duplicate messages from appearing in an employee's activity chatter when they are automatically enrolled in an eLearning course more than once. It keeps employee records cleaner and reduces confusion from repeated notifications.
Original PR description
Steps to reproduce: - connect with a user with an employee record - recreate a new eLearning course - enable debug mode - add "Role / User" to "Auto Enroll Groups" fields => message is duplicated in the employee's chatter `_action_add_members` in `website_slides` is designed to be idempotent (calling it twice is a no-op if the partner has already joined) but the override in `hr_skills_slides` is not. We have many many duplicated messages on odoo.com (see task) task-6508615 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289644 Forward-Port-Of: odoo/odoo#284483
This fix ensures tracked field changes appear in the correct chatter filter instead of being mixed into conversations. Users will see clearer message organization, making it easier to review discussions separately from recorded changes.
Original PR description
Previously, the chatter filters only considered notification messages. Since field tracking messages are now stored as tracking messages, they no longer appeared in the 'Tracked Changes' filter and were incorrectly included in the 'Conversations' filter. This PR updates the chatter filters to correctly handle tracking messages, ensuring that each filter displays the appropriate messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue in the HTML editor where turning large heading text into a list could make bullets or numbers appear too far to the left. Lists now automatically adjust their spacing based on the text size, improving document formatting consistency.
Original PR description
Problem: Creating a list on a header block with large font size content causes the list marker/bullet to overflow to the left. Cause: `ListPlugin.blockToList()` wrapped block elements into a list without invoking `this.adjustListPadding(list)`, leaving the list padding unadjusted for larger font sizes. Solution: Call `this.adjustListPadding(list)` in `blockToList` so that proper inline padding is set based on the list item content font size. Steps to reproduce: - Create a header block (e.g. Header 4). - Change the font size of the header content to be bigger. - Apply a list on the content. => Observe that the list marker overflows to the left. opw-6542903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286975
This fix prevents blank-looking link previews when website metadata contains only spaces. The link popover now falls back to the URL or hides empty details, making links clearer and avoiding confusing empty clickable areas.
Original PR description
Problem: When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: " "`), the link popover displays an empty clickable preview area.…
Problem: When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: " "`), the link popover displays an empty clickable preview area. Cause: `LinkPopover` assigned raw metadata values directly. Non-empty whitespace strings evaluate to truthy values in JavaScript (`" "` is truthy), preventing fallback to the default URL or empty string. Solution: Trim the metadata values (`og_title`, `og_description`, `og_image`) when populating state so that whitespace-only values evaluate to empty strings and trigger appropriate fallbacks. Steps to reproduce: - Open HTML editor. - Add a link with URL `https://netorg4182089.sharepoint.com/:v:/s/projects/IQD72ajP3WOBT4jcAu_1qLfIAamL9lvrq4ls1Bs9XCyXJvw?e=vQ9wH3`. - Open the link popover. => Observe that the popover title falls back to the URL instead of showing an empty clickable space. opw-6564118 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288188
French VAT report downloads now correctly read stored report attachments after a platform change. This prevents failures when reusing VAT reports for the same period, helping accounting users access the expected report data reliably.
Original PR description
Since https://github.com/odoo/odoo/pull/244421 in 19.3, fields.Binary return BinaryValue so the way we decode field attachement (model 'account.report.async.document') is not correct anymore. This commit apply the new way to decode. opw-6581477
Timesheet email suggestions from designated blocked addresses, such as online@odoo.com, will no longer be automatically linked to projects or tasks. This prevents incorrect task or project assignments in rare cases and keeps timesheet suggestions more accurate.
Original PR description
Before this commit, incoming email suggestions were automatically matched to tasks or projects whenever the sender’s email address could be linked to a partner in the database. In certain niche cases, this resulted in unwanted matches for specific email addresses or partners. After this commit, Email suggestions originating from designated addresses (e.g., online@odoo.com) are now excluded from task/project matching. task-[6414046](https://www.odoo.com/odoo/project/4105/tasks/6414046) Forward-Port-Of: odoo/enterprise#130536 Forward-Port-Of: odoo/enterprise#125645
This fix makes Field Service planning tests use a consistent employee timezone so test results no longer vary depending on demo data settings. It helps keep automated checks reliable and prevents false failures during validation.
Original PR description
Employees created in TestPlanningFieldServiceCommon had no explicit tz, so they inherited the acting user's timezone. With --with-demo that user's tz is Europe/Brussels, shifting the resource calendar's work hours by 1h in January and making test_planning_slot_allocated_hours_on_multiple_resources compute 7 allocated hours instead of the expected 8. runbot-946587 Forward-Port-Of: odoo/enterprise#131570
This fix prevents action buttons from appearing on working files when no attachment has been uploaded, reducing confusion for users. It also keeps budget report amounts correctly formatted when a user opens a value for editing and clicks away without making a change.
Original PR description
Hide Open Document on working files when no attachment Problem: In working files checks with attachment, Open Document button and trash icon are visible even if there is no attachment uploaded yet.…
Hide Open Document on working files when no attachment Problem: In working files checks with attachment, Open Document button and trash icon are visible even if there is no attachment uploaded yet. Cause: We check for existence of attachment by `t-if="record.attachment_ids"`, but `record.attachment_ids`, `record.attachment_ids.value` and `record.attachment_ids.raw_value` are all truthy even if there is no attachment uploaded yet. Fix: Use `invisible="not attachment_ids"` just like before. *** Fix formatting when clicked outside without any change Steps to reproduce:- - Create a budget with a P&L report. - Set a value in a cell. - Then press the edit amount, click somewhere else without changing the amount. - The amount is no longer formatted properly. Cause: When user clicks edit, we populate formatted value for locale format type but when user clicks outside without change, in function `onBlur` we compare populated amount(which is formatted) with cell's no format value. So it mismatches and `focused` is never set `false`. Fix: Make getter `editableValue`, which returns `editableNumericValue` for locale format type and no format value otherwise. Now use this `editableValue` in `onFocus`, `onBlur`(this solves the bug) and `inputValue` to make it more clear. *** [task-6413368](https://www.odoo.com/odoo/project/967/tasks/6413368)
A rental planning test was corrected to account for local time zones when comparing rental pickup and planning slot times. This prevents false test failures during early-morning hours and helps keep release validation reliable.
Original PR description
**Issue:** `test_payment_renting_product_available` test is failing when executed between 0:00 AM and 2:00 AM in Brussels timezone (UTC+2): ``` AssertionError: datetime.datetime(2026, 6, 22, 16, 0) != FakeDatetime(2026, 6, 21, 16, 0) : The planning slot should begin at the same time as the picking time. ``` In the database the datetime is stored in UTC, which is the previous day for the example above. In `test_payment_renting_product_available` test, the datetime is passed to `datetime.combine()` function that naively uses the date part, which leads to a one-day delta. The datetime should be converted to the working timezone before being passed to `datetime.combine()`. runbot-940435 Forward-Port-Of: odoo/enterprise#131944