Tuesday, March 4, 2025
7 changes · saas-18.1
Resolved issues and error corrections
This fix stops saved web actions from repeatedly storing duplicate hidden data when a page is reloaded. Users opening lazy-loaded screens such as dashboards should no longer hit browser storage errors after repeated refreshes.
Original PR description
- Open a lazy load client action (e.g. dashboard spreadsheet); - Reload (F5) repeatedly. Before this commit, a `QuotaExceededError` was thrown. This error occurs because: - The action is processed,…
- Open a lazy load client action (e.g. dashboard spreadsheet);
- Reload (F5) repeatedly.
Before this commit, a `QuotaExceededError` was thrown. This error occurs
because:
- The action is processed, and an `_original_action` (a string copy of the
action) is added;
- The action is executed (a client action), in this case is a lazy load client
action function.
- The function returns, the same action to be re-executed (this time with the
lazily loaded component client action);
- The action returned by the function (which already has an
`_original_action`), is processed, and an `_original_action` is added (a
string copy of the action, that already contains a string copy of the
action);
- Doing this multiple times on each reload will add a new layer of string copy
of the action, until there is a memory error.
This problem was introduced by [1], prior to this commit, the saved actions
were only used if it was a dynamic multi-record action.
[1]: https://github.com/odoo/odoo/commit/c0ae72b25e935790c6e3b1fd805aadbd2fff75c7
opw-4619396When a visitor starts a live chat in one browser tab, other open tabs now begin listening for chat updates as soon as the chat is known there. This ensures new messages arrive in real time without requiring the visitor to reload the page, while still avoiding unnecessary background activity until needed.
Original PR description
Before this PR, creating a live chat in a first tab would correctly open the chat window in a second tab. However, messages were not received in real-time before the second tab reload. This issue occurs because the bus service is not started in the second tab. To solve this issue, the bus service is now started when there is at least one thread known locally. The behavior stays lazy, nothing is starting until required. part of task-4607689 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
Point of Sale users in Australia can now select Tyro as a payment terminal option directly from the terminal selection widget. The update also keeps Enterprise-only terminal options hidden for Community users, reducing confusion and manual setup.
Original PR description
A new `pos_tyro` module for the Australian payment terminal Tyro was added in https://github.com/odoo/enterprise/pull/79432, but there was no way to select it other than installing the module manually. This commit adds Tyro to the payment terminal selection widget. Since it is an Enterprise module, it also adds additional filtering to hide enterprise modules from community users in the widget. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat conversations will no longer open automatically while the chat hub is in compact mode. This avoids unexpected chat windows appearing later when agents return to the normal view, making the experience less intrusive while preserving automatic opening outside compact mode.
Original PR description
Live chat windows automatically open for new conversations to improve agent efficiency. However, when the chat hub is in compact mode, these windows are still opened in the background and become visible when returning to normal mode, which feels too intrusive. Some agents prefer chats to open automatically, while others do not. This PR prevents automatic chat openings in compact mode, offering a better compromise for both. task-4614339 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
Fixes a mobile-only issue that caused the app to crash when users tried to edit a message. This improves reliability for users managing conversations from phones and adds proper mobile test coverage to prevent the issue from returning.
Original PR description
Before this commit, editing a message on a mobile device resulted to a crash. This happens because the 'edit' message action relies on presence of `props.messageEdition` on the component, which is…
Before this commit, editing a message on a mobile device resulted to a crash. This happens because the 'edit' message action relies on presence of `props.messageEdition` on the component, which is present on `Message` but not `MessageActionMenuMobile` that is used in mobile. This commit fixes the issue by propagating the message edition hook from `Message` to `MessageActionMenuMobile`, so that message edition is possible without crash in mobile. There was a test to cover mobile, but due to test not being tagged as mobile, it was running with the screen size of mobile but without user agent as a mobile. The `MessageActionMenuMobile` component is shown when the device is considered mobile, therefore the mis-tag resulted in a test that takes into account screen size of mobile but on a desktop environment, thus this menu wasn't shown. The test has been fixed as a result. Bug in action with crash: 
Payroll batches now select employees based on contracts that are active during the batch period, reducing errors from incorrect contract selection. This helps ensure payslips in a batch use the right contract and payroll structure, improving payroll reliability across standard, accounting, and localized payroll flows.
Original PR description
* = hr_payroll{,_account}, l10n_{be,in}_hr_payroll
Problem
----------
- An employee can not have multiple payslip in a batch
- Wrong contract can be selected in the wizard
- Difference between structure payslip's structure and contract's one
Objective
----------
- Base the employees selection on active contracts running in the batch period
- Update tests to follow the good behaviour
Solution
----------
- Link payslip employee wizard with a batch one time with the context
task-4483393This fix ensures that when an employee selects an existing bike for a new contract, the bike is properly reserved for that future driver. It also clears hidden bike selections when bike transport is removed from a contract, preventing blocked or duplicate bike choices in later offers.
Original PR description
When an existing bike is selected when signing a new contract, the future driver is not set on the biked, so it is not reserved and can be taken by multiple people. Also when you unselect 'transport_mode_bike' on an existing contract, the bike_id is not removed (but invisible), which leads to prevent any person with this kind of contract to select a bike in an offer. (same behavior with new bike, the model is not removed)