Tuesday, June 30, 2026
15 changes · saas-19.4
Enhancements to existing features
The check status button is now disabled when a user does not have permission to edit it. This avoids access errors and makes the interface clearer by only allowing actions that the user can actually perform.
Original PR description
Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown. After this commit: Disable check status button if user don't have write access on check. task-5951364 Forward-Port-Of: odoo/odoo#271447
When a Swedish VAT number is entered, Odoo can now automatically extract and fill in the company’s registry number. This reduces manual entry and helps keep business identification details consistent.
Original PR description
Organization number is part of the VAT number Official reference: https://www.skatteverket.se/foretag/moms/kopavarorochtjanster/inkopfranandraeulander/kopavarorfranandraeulander.4.3a7aab801183dd6bfd380005738.html > I Sverige börjar alla VAT-nummer med bokstäverna SE (landskoden) och avslutas med siffrorna 01. Om du har en enskild firma följs landskoden av de 10 siffrorna i ditt personnummer. Om du har ett bolag eller en förening följs landskoden av de 10 siffrorna i organisationsnumret. VAT-numret skrivs utan bindestreck. which translates to > In Sweden, all VAT numbers begin with the letters SE (the country code) and end with the digits 01. If you are a sole proprietor, the country code is followed by the 10 digits of your personal identification number. If you are a corporation or an association, the country code is followed by the 10 digits of your organization number. The VAT number is written without a hyphen. Forward-Port-Of: odoo/odoo#269590
Resolved issues and error corrections
This update fixes an editing issue where the cursor could jump to the wrong side of template content after deleting text. It helps users edit email templates more smoothly and avoids unexpected cursor behavior in <t> blocks.
Original PR description
## Problem:
`<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block.
## Solution:
We will remove "T" from the list of self-closing tags.
## Steps to replicate (runbot v18):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block.
opw-6124284
Forward-Port-Of: odoo/odoo#272285
Forward-Port-Of: odoo/odoo#266816Code cleanup and technical improvements
This change removes old, unused code related to the Gantt progress bar redesign. It helps keep the product codebase cleaner and easier to maintain without changing how users work.
Original PR description
Cleans up residual dead code left over from the progress bar redesign in https://github.com/odoo/enterprise/pull/118045. Since the `GanttRowProgressBar` component is no longer referenced anywhere in the new layout architecture, its corresponding files have been deleted.
This change prevents a warning from being shown or logged for every uploaded document when automatic OCR is turned off. It reduces noise in the system logs and makes it easier to spot messages that actually need attention.
Original PR description
The warning "Automatic OCR does not apply to this document" was logged for every upload when automatic OCR isn't enabled, it isn't very useful. Manually backported as branch 19.4 was created during fw-port of original PR. opw-[6232122](https://www.odoo.com/odoo/unassigned-tasks/6232122) X-original-commit: 49b7d2bdc8ba20f6286c51c2721045cda36c4b8e
The website generator now uses a more general page limit note instead of showing a specific number. This gives the system more flexibility to adjust page limits later without confusing users.
Original PR description
Page limit note fixed by being more general instead of stating a blatant 200. This gives us more leeway to control the nbr of pages IAP side. X-original-commit: d82ef3a10c671972131bab7d28c76cce82e55105
This change fixes a timing issue in the WhatsApp channel test so message status updates are applied in the correct order. As a result, the test no longer fails intermittently, making the WhatsApp chat experience more reliable to validate.
Original PR description
The "Allow SeenIndicators in WhatsApp Channels" test awaited the bus subscription so the simulated seen notification is no longer dropped, but that exposed a second race between the init RPC and the bus return. openDiscuss does not await the channel data fetch (channels_as_member), whose response carries each member seen_message_id=false. When it is applied after the _sendone seen notification, it clobbers the member back to unseen, the indicators never render, and the assertion times out. Wait for the message to render before simulating the seen notification: the thread message comes from the message fetch, which only runs once the channel (with its members) is loaded, so the seen data is guaranteed applied. This mirrors the message seen indicator tests in mail. https://runbot.odoo.com/odoo/error/242021 Forward-Port-Of: odoo/enterprise#122041
The system restores a previous performance optimization when checking access rights for views. This keeps the fix for earlier loading issues while improving speed again, so users should benefit from a smoother experience without the earlier slowdown.
Original PR description
This reverts commit f2442a193584d6a2ecc8af4f9cd06002148211f5, which was avoiding method ir.access._get_all_access() to fail on not yet loaded fields. Commit 1570432f930baac8b018f7339338057ac8c2226c now avoids the method to fail in such cases. Therefore the de-optimization is no longer necessary.
This update corrects the color shown in the Timesheets grid when an employee’s schedule includes fractional working hours. It prevents the app from marking a cell as warning/orange by mistake when the worked time exactly matches what is expected.
Original PR description
## Issue In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color…
## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.
## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
- Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__
## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157
We obtain the following values:
```js
> monday = section.cells[1]
> monday.value
8.333333333333336
> workingHours[monday.column.value]
8.333333333333332
> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```
This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172
## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.
opw-6193181
Forward-Port-Of: odoo/enterprise#121463This update adjusts the holiday calendar side panel to work with the latest Owl framework version used in Odoo. It helps keep the scheduling interface stable and prevents issues caused by outdated component behavior.
Original PR description
This commit is a follow-up of 197d0ca5, as part of the Owl 3 migration, replace onWillUpdateProps hook with the appropriate Owl 3 alternatives 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
When users switch companies while viewing a payroll pay run, the system now checks access before reloading the page. This prevents a brief error message from appearing and takes users directly back to the pay run list when the record is not accessible in the new company context.
Original PR description
Steps to reproduce: 1- Open a payrun 2- Switch companies Issue: You get an access error for a moment and then get redirected to payrun list view Cause: When switching companies, the payrun reloads but since it is in the context of a different company, you get an access error. Solution: First check in js before fetching that you have access to the payrun, if not, redirect to the list view instead. Task-6008140 Forward-Port-Of: odoo/enterprise#120004
We fixed an automated test in the chat features that was sometimes failing at random. The check now looks directly at the chat title instead of relying on a brief loading moment, making test runs more reliable and reducing false failures.
Original PR description
The hoot `:text('X')` pseudo-class matches an element only when its whole inline text equals "X". `.o-mail-ChatWindow:text('slytherins')` therefore matched the chat window only during the brief frame where it showed nothing but its title, before the thread body (start message, composer) was rendered. Catching that frame is a race, so the assertion times out intermittently on runbot.
Assert against the title element itself: add a dedicated `o-mail-ChatWindow-name` class on it and match it with `.o-mail-ChatWindow-name:text('X')`. This is exact and no longer depends on the rest of the window being empty.
https://runbot.odoo.com/odoo/error/939914
Forward-Port-Of: odoo/odoo#272567
Forward-Port-Of: odoo/odoo#272380This update fixes an unstable automated test in the messaging app that could fail intermittently under slower conditions. It does not change user behavior, but it helps ensure future releases are tested more reliably.
Original PR description
The "Jump to old reply should prompt jump to present (RPC small delay)" test clicked the jump-to-present button right after clicking the in-reply, without waiting for the jump to the old reply to render. The button only shows once that load has settled, so under load the button could still be absent when the click polled for it, making the test flaky. Wait for the messages to be reloaded around the old reply before clicking, mirroring the non-delayed sibling test. https://runbot.odoo.com/odoo/error/941200
This change moves a self-order-related check out of the standard Point of Sale flow and into the self-order feature where it belongs. It helps prevent failures in automated testing and keeps the regular Point of Sale behavior aligned with its intended scope.
Original PR description
This commit moves the usage of `has_valid_self_payment_method` from `point_of_sale` to `pos_self_order`, where it belongs. The method usage was introduced in https://github.com/odoo/odoo/pull/269502, causing runbot failures Runbot Errors- [941124](https://runbot.odoo.com/odoo/error/941124), [941125](https://runbot.odoo.com/odoo/error/941125), [941126](https://runbot.odoo.com/odoo/error/941126)
Searching messages could previously send the same request twice, which could slow down the interface and create unnecessary load. This update ensures the search only runs once per action, improving responsiveness and reliability when users look for messages.
Original PR description
Previously, searching messages could trigger two RPCs for a single search. This was caused by the search effect executing 'run()' even after the search had already been performed. This PR ensures that the search effect only clears results when inactive, preventing duplicate search RPCs. task-6311095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr