Tuesday, March 4, 2025
5 changes · saas-18.2
Resolved issues and error corrections
This fixes an internal mail test helper so automated checks better match how users click between chat elements. It reduces false test failures around chat notification counters, helping keep releases stable without changing user-facing behavior.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/200037 PR above added a new test that resulted in frequent runbot failures: ``` Failed assertions: 1. [toBe] Failed to find 1 of…
Follow-up of https://github.com/odoo/odoo/pull/200037 PR above added a new test that resulted in frequent runbot failures: ``` Failed assertions: 1. [toBe] Failed to find 1 of ".o-mail-ChatHub-compact" with text "1" (Timeout of 3 seconds). Found 0 instead. > Expected: true > Received: false 2. [errors] 1 unverified error(s) Error during test: Failed to find 1 of ".o-mail-ChatHub-compact" with text "1" (Timeout of 3 seconds). Found 0 instead. ``` This happens because the test had a chat window open, enabled the compact mode of chat hub, then posts a message and assert there's a counter on the chathub compact button. Everything works fine when a human do these interactions. However the test failed because there was no counter. This comes from chat window modeling that was thinking the composer was still focused, therefore it was marking the conversation as read, leading to consuming the "1" counter. Composer was kept in "focused" state because when programmatically simulating a `click`, the detection of loss of focus is made with a `focusout` event that is triggered normally on the previously focused element. In HOOT, the `@mail` click test helper was not triggering `focusout` on the previous element. This commit fixes the issue by triggering `"focusout"` on the previously active element in the `click` helper of `@mail` when the previous element is not the same as the next. runbot-159692 https://runbot.odoo.com/runbot/build/76027155
Website forms now keep their message area intact after a visitor submits a form and an editor later modifies it. This prevents confusing error popups and ensures future form submission messages can still be shown correctly.
Original PR description
Since [1] when the form public widget was converted into an interaction, the `s_website_form_result` span is removed if it had been re-rendered (e.g. by submitting the form) before entering edit mode. Because of this, the result span could not be located anymore to display further messages in case it was saved in that corrupted state. This commit fixes this by neutralizing the implicit cleanup that removes the rendered element, and manually emptying it instead. Steps to reproduce: - Drop form - Save - Submit - Edit - Add a description on the first field - Save - Submit => An error popup was displayed. [1]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f
The survey form layout has been adjusted so the responsible person and restricted users fields line up properly on medium and larger screens. This improves visual consistency and makes the form easier to read without changing how surveys work.
Original PR description
In the survey form view, on screens of size medium and larger, the line containing the 'responsible' and 'restrict_user_ids' fields is not correctly aligned with the line below. This seems to be due to the background image taking up space occupied by the above two fields. To solve the problem, we modify the padding left of the fields, for the relevant screen widths (breakpoints). task-4605729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal website shop test so it works even when the timesheet sales module is not installed. It helps keep automated quality checks reliable across different database configurations, without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Have a database without `sale_timesheet` installed; 1. run `TestWebsiteSequence` test suite. Issue ----- ValueError: No record found... Cause ----- Commit 32ad7ab3faf52 updated the test to account for a `sale_timesheet` product that cannot be deleted or archived, but didn't check whether the module was actually installed. Solution -------- Revert changes to the test that were added in the commit, and instead archive the product via `cr.execute` to bypass the `write` method where the restriction exists. runbot-111883
This update adjusts internal report tests so they work correctly when only invoicing is installed, without the full accounting app. It helps prevent false test failures caused by expected account number conflicts during chart of accounts setup.
Original PR description
When loading the chart of accounts with invoicing only installed (not accounting), we create additional accounts for the outsanding amounts on the bank/cash journals. These accounts are then clashing with 101404, as expected. runbot-134653