Wednesday, April 23, 2025
8 changes · 18.0
Resolved issues and error corrections
The Tags filter in the website shop sidebar now behaves like the other filters, allowing shoppers to collapse or expand it. Its spacing was also adjusted for a more consistent and polished shopping page layout.
Original PR description
<b>Steps to reproduce:</b> 1. Go to website > Shop > Scroll to tags filter (If tags aren't visible in the sidebar, go to Sales > Configuration > Product Tags > create tags) 2. Notice that Tags filter cannot be collapsed unlike other filters 3. Observe that margins and spacing don't match other filter components <b>Issue:</b> The "Tags" filter on the website shop sidebar lacked a collapsible header, unlike other filters such as "Price Range". This caused UI inconsistency. Additionally, the margin and spacing did not align visually with other filter components. <b>Solution:</b> Applied Bootstrap collapse classes to the Tags filter to enable accordion-style toggling. Adjusted margin and structure to match the layout of other sidebar filters for visual consistency. opw-4702463
This update adjusts an internal web test so it remains reliable with newer Chrome versions. It does not change the user experience, but helps keep automated quality checks stable and trustworthy.
Original PR description
Since Chrome 135, the "Keep scrollTop when loading records with load more" unit test fails with a scrolling value way higher than expected. In practice, the scroll in the test goes down to the "Load more" button after it has been clicked instead of keeping scroll to the same value as before the loading of the "more" items. Weirdly, it doesn't look to be an actual issue when performed by the user, but only in the test suite. This commit works around that issue by using `element.click()` followed by waiting for an animation frame instead of using `contains().click()`, because... well, the two helpers behave slightly differently. 🤷
This fix improves how website mega menus appear when using vertical navigation layouts such as sidebars or hamburger menus. It prevents menu items from overlapping, making navigation cleaner and easier for visitors to use.
Original PR description
Steps to Reproduce : 1. Add a Mega Menu through Menu Editor 2. Switch the header template to Sidebar 3. Once done --> Open the mega menu; it will overlap with one another. Issue: Vertically aligned navbars like the sidebar and hamburger navbar, have styling issues with the mega menu. The mega menu is designed according to the full width of the screen, which leads to not look good mega menu when opened in a limited-spaced navbar. Fix: This commit adds the style particularly to vertical navbars, such that the styling of the mega menu is proper even in these navbars. Task: 4684074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595
This fixes an intermittent automated test failure by adding wait steps before interacting with the PDF signing area. The change helps keep Belgian payroll contract tests reliable without changing the user-facing payroll workflow.
Original PR description
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the
setTimeout(() => this.initializeIframe(), 1);
interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.
I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...
https://runbot.odoo.com/odoo/error/181583Updating pivot settings in spreadsheets no longer removes the sorting users applied to pivot values. This preserves the expected spreadsheet view after changes such as adjusting filters or domains, reducing repeated manual work.
Original PR description
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934
The Luxembourg payroll module no longer tries to load missing setup files during its scheduled payroll data update. This prevents an error when administrators run the update action, improving reliability without changing payroll behavior.
Original PR description
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action.
**Steps to produce:**
- Install `l10n_lu_hr_payroll` module.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.
`ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'`
Here, `_get_data_files_to_update` method at [1] attempts to load the `hr_salary_rule_data.xml` and `hr_gratification_rule_data.xml` files, which are not present in the codebase.
[1] - https://github.com/odoo/enterprise/blob/809fda39b439edf6259ade445e396e722c1bb53a/l10n_lu_hr_payroll/models/hr_payslip.py#L219-L220
This commit ensures the removal of invalid file references to prevent errors when executing the scheduled action.
Sentry - 6316151728This update adjusts a Helpdesk portal test so it waits for the final expected result instead of ending while background page content may still be loading. This reduces false test failures and helps keep Helpdesk releases more stable without changing customer-facing functionality.
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748