Wednesday, June 25, 2025
12 changes · saas-18.4
Resolved issues and error corrections
Saving changes in the website menu editor now preserves any page edits already made in the website editor. This prevents users from accidentally losing their work when adjusting navigation menus during website updates.
Original PR description
This plugin fixes a bug where making changes on the editor, opening the menu editor and clicking save would cause the changes to be discarded. Steps to reproduce: - Open editor - Make any change - Click on any navbar element (like Home) to open the navbar popover - Click on the edit menu button in the popover - A modal will open, click save - All changes have been discarded After the fix the changes will be saved when clicking save in the menu editor modal
This fixes a crash that could occur when users clicked cells in spreadsheet dashboard pivot tables using text filters. The spreadsheet now correctly reads text filter values after an internal format change, improving dashboard reliability.
Original PR description
Since 31a443fc06b38d129e7da0fd0c11304d08ac8480, the text filter value is now an array of strings instead of a single string. This commit updates the getters used to retrieve the filter value from the pivot formula to handle this change correctly. Steps to reproduce: 1. Open the dashboard "Pipeline" 2. Click on a cell in the "Top cities" column 3. Boom Task: 4894663 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
This fixes an error that could occur when users applied multiple grouping levels in views with expanded groups enabled. It helps keep grouped reports and lists usable instead of showing a crash.
Original PR description
Since 26c37c9c070107f8bd753cb8a6d8343384fdd7bf, when performing nested Group
By on a view with expand = True, a traceback was raised when applying 2 or more groups.
```
File "/home/odoo/Documents/odoo_projects/odoo/addons/web/models/models.py", line 447, in web_read_group
self._add_groupby_values(groupby_read_specification, groupby, groups)
File "/home/odoo/Documents/odoo_projects/odoo/addons/web/models/models.py", line 480, in _add_groupby_values
id_label[0] for group in current_groups if (id_label := group[groupby_spec])
~~~~~^^^^^^^^^^^^^^
TypeError: string indices must be integers, not 'str'
```
This was because we expected 'group' to be a dict, but it was a string.
This commit change the 'group' creation, by adding the right dict in it.
no-taskThis fix stops website builder option fields from being overwritten by older background updates while a user is still typing. It helps prevent accidental loss of recent input and makes editing website settings more reliable.
Original PR description
[FIX] html_builder, website: prevent update input in preview
Here is the flow that this commit fixes:
- The user types something ("A") as input and clicks somewhere else to
commit its change.
- The custom action linked to the input in asynchronous and it takes
time to finish.
- The user types something else ("B") and stays on the same input (no
update of the input state so no update of the UI).
- The custom action of "A" finishes and updates the state of the input.
-> "A" is displayed in the option input and "B" is lost. If the user
continues to type, it will not be the wanted input.
Related to task-4367641This fixes a timing issue where older, slower data requests could overwrite newer results after a user sorted a list. List views now keep the most recent user action visible, reducing confusion and preventing outdated information from reappearing.
Original PR description
- Open a view list; - The cached data are shown; - The RPC (web_search_read) to recover the latests data is very slow. - The user sort the list and this RPC will return immediatly; - The list will be updated with the latests sorted data. - The first RPC, which was very slow, returns (with a non sorted data). Before this commit, the list will be updated with the retuned RPC. This is an issue because the user has already performed another action (like asking to sort the list). The last returned RPC should be ignored and not appllied. Now, the relational model will only update the data if no other load is performed. task-id 4896533
The domain selector once again offers the "in" filter operator broadly, while the separate tree editor will move toward a simpler operator set later. This preserves familiar filtering options for users and avoids prematurely limiting advanced filter building.
Original PR description
This commit partially reverts the commit https://github.com/odoo/odoo/commit/cf944e460cdb7ff371a56479e2fed89930680061. The tree editor will be developed in another direction where less operators are available (see task 4894524).
Website builder color pickers now refresh when theme colors or palettes are changed, so users see the latest branding colors in the editor. This prevents outdated color options from appearing and makes theme customization more reliable.
Original PR description
*: web, website
Before the refactoring to html_builder, to replicate the `--o-ccX-...`
variables available within the iframe, the website wysiwyg used CSS
custom properties (prefixed with `--we-cp-`) set on the main document.
This was lost during the refactoring, causing the "Theme" tab of the
builder colorpickers never to be updated after modifying the theme
colors.
This commit reapplies those variables, prefixing them with `--hb-cp-`
(for "html_builder copy").Several spreadsheet dashboards have been refreshed to the latest dashboard format. This helps ensure reporting views for sales, invoicing, events, expenses, timesheets, live chat, point of sale, restaurants, and warehouse metrics stay current and work consistently.
Original PR description
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
This update fixes how image and background shape choices appear in the website builder, so users can see the correct previews instead of repeated or oversized shapes. It also restores expected selector styling, tab behavior, scrolling, and translated labels, making the design tools easier and clearer to use.
Original PR description
### [FIX] website, html_builder: fix image shapes selector Since [1], the builder shape selector wasn't displayed properly: - Each shape took too much space (especially in width) - All the shapes…
### [FIX] website, html_builder: fix image shapes selector Since [1], the builder shape selector wasn't displayed properly: - Each shape took too much space (especially in width) - All the shapes were loaded with the visuals of the first one (diamond) While the 1st issue was just due to the CSS not being updated, the 2nd one is tied to how SVG works: the shapes use a filter referenced by an id. That id is identical for all shapes: this isn't a problem as long as each SVG is confined in its own file, but once they are all loaded on the same HTML document, the reference points to the 1st match in all cases: the diamond shape. To solve this, this commit partially reverts commit [1] through an additional prop `svgCheck` on the html_builder `Img` component. Setting it to false bypasses the svg check and loads a simple `<img>` element instead of forming a SVG element. [1]: http://github.com/odoo/odoo/commit/3cc5ff6e96493f2b068090f880987def3787895e ### [FIX] website: fix background shapes selector Since [2], the shapes in the builder's background shapes selector were not displayed properly: they all took the whole space available in the select button, instead of being applied specific CSS rules for each shape. This is simply fixed by bringing back the specific shape class in the `ShapeSelector` template. ### [FIX] html_builder, website: design pager builder select Since [2], the design of the shape select (both the image shapes and the background shapes) is broken. Before a proper redesign, this commit resets the styles to something similar to what it looked before the refactoring. It also reapplies the active style on the pager tabs, as well as the scroll behavior. [2]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 ### [FIX] website: translate shape selector labels task-4367641
The website builder date and time picker now handles empty, cleared, and invalid values more reliably. This prevents confusing display errors such as “NaN” in countdown snippets and keeps the editor preview aligned with the selected date and time.
Original PR description
This commit addresses several regressions that were introduced during the website refactor [1]. The primary goal is to restore and improve the functionality of the `BuilderDateTimePicker`. The…
This commit addresses several regressions that were introduced during the website refactor [1]. The primary goal is to restore and improve the functionality of the `BuilderDateTimePicker`. The following issues have been resolved (to reproduce: drop an `s_countdown` snippet on the page, use `Due Date` option): - Empty input fields now correctly default to the current date and time - Clicking the "Clear" button now resets the input to the current date and time (previously, it only emptied the input) - Invalid date or time inputs now revert to the last valid input (to reproduce: choose a valid date, then type `INVALID` in the input field) - `NaN` is no longer displayed on the snippet while the user is typing (previously, `NaN` appeared on the snippet for invalid or empty inputs, even in preview) Additionally, the `default` props have been removed as the component now consistently defaults to the current time. The input field is now synchronized with the `DateTimePicker` to provide a more seamless user experience (the field displays the same date while using the `DateTimePicker` in preview). [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Related to task-4367641
Several spreadsheet dashboards have been updated so their date filters work correctly after a recent platform change. This restores reliable dashboard views across accounting, CRM, helpdesk, payroll, recruitment, marketing, manufacturing, and purchasing areas.
Internal users without Planning app access can once again open the shift calendar to view their own shifts and open shifts. The change hides a resource filter that required higher Planning permissions, preventing unnecessary access errors.
Original PR description
Before this commit, the internal user without any access to planning app can no longer access to the calendar view of planning.slot model to see his shifts and the open shifts. The reason is because the new filter added is only accessible to planning user. This commit hides the new filter on resources when the user has no access to planning app. Steps to reproduce: ================== 0. install Planning app 1. Create an internal user without any access to planning app (or remove planning access to Marc demo) 2. Log as Marc demo (or new user created in step 2) 3. Go to planning app and switch to calendar view Expected Behavior: ----------------- The user should be able to access to the calendar view without any issue. Current Behavior: ---------------- An access error is raised because the current user cannot access to `planning.calendar.resource` model which is only accessible to users with planning access rights. runbot-error-227622