Daily updates from Odoo
Thursday, July 11, 2024
4 changes · saas-17.2
Resolved issues and error corrections
Fixes a broken guided tour in Website Slides so users can complete the walkthrough as expected. The update corrects timing and button-targeting issues caused by earlier library and design changes.
Original PR description
**Issue** From v17.2, the website_slides tour is not working because of some changes in the tour library. Commit from where I think the bug is coming https://github.com/odoo/odoo/commit/b334055c82c4350b4122e620ae76179a9fc4eaa2 and later due to the website design change another step was also failing and that should be coming this commit https://github.com/odoo/odoo/commit/80e3f53550b7ed74ac18bb09ea542c9e77c9a61d **Technical** The "Add to content" is loading before our frame is ready due to this the position of the pointer was wrong. Due to the design change tour was not able to point the publish btn **After this PR** Now the tour is working properly. Task-3960962
This update refreshes the spreadsheet engine with fixes that make charts easier to read, improve formula matching behavior, and reduce unnecessary recalculations. Users should see more reliable spreadsheet results and smoother performance, especially in larger sheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9f2068549 [REL] 17.2.16 Task: 0 https://github.com/odoo/o-spreadsheet/commit/86adb37bf [FIX] charts: truncate labels…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9f2068549 [REL] 17.2.16 Task: 0 https://github.com/odoo/o-spreadsheet/commit/86adb37bf [FIX] charts: truncate labels by default Task: 3958962 https://github.com/odoo/o-spreadsheet/commit/de8b6b1a3 [PERF] evaluation: don't evaluate needlessly Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/565dbdc9d [PERF] evaluation: invalidate spreading in batch Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/d164e4215 [IMP] demo: add large demo data set for array formulas Task: 4036899 https://github.com/odoo/o-spreadsheet/commit/dd9f5a386 [FIX] functions: "*" doesn't match empty string Task: 4023057 https://github.com/odoo/o-spreadsheet/commit/62f4af81a [FIX] functions: match empty cells Task: 4023057 https://github.com/odoo/o-spreadsheet/commit/81381a425 [REV] chart: avoid useless chart updates Task: 4029016 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes a display issue where popups or overlays inside embedded livechat could fail to appear when they were already queued before the chat area finished loading. Visitors should now see the right livechat interface elements consistently without duplicate overlays elsewhere on the page.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from…
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from visitor's perspective. The reason for shadow DOM is to use exactly same style and behaviour of livechat like in Discuss as internal users. The shadow DOM has to sustain its good working by itself, so it also needs to deploy some required main components like overlay container. In website, there's also an overlay container, and since they share the same stateful service (overlay_service), we do not want to display the overlay twice. So PR above solved the issue by allowing to make overlay with a provided `rootId`, which when set it contains the `id` attribute of the root node of the overlay that has to manage the overlay. This allows to clearly determine which overlay container is responsible to display the appropriate overlay. Code above was however buggy: it relies on `isVisible(overlay)`, whose computation requires `rootRef.el`. Refs' el are not determined on the 1st rendering of the overlay service. This is not a problem when the overlay container is 1st mounted without any overlay, but if it's being registered with some overlays, mounting the overlay container afterwards results in the non-showing of the overlay. The `rootRef` is important to find out the "global" root node id, i.e. the shadow DOM root id. This commit fixes the issue by rendering again overlay container after mount when there are some pre-registered overlays.
Users who cannot edit projects or lunch products can once again mark them as favorites. This restores a convenient personalization option that was unintentionally blocked by a recent access-rights change.
Original PR description
## [FIX] project: let project user to set a project as favorite Before this commit, since the project user cannot edit a project and a recent fix (https://github.com/odoo/odoo/pull/168464) ensures…
## [FIX] project: let project user to set a project as favorite Before this commit, since the project user cannot edit a project and a recent fix (https://github.com/odoo/odoo/pull/168464) ensures the boolean_favorite widget is readonly is the field is readonly or if the record is readonly then the project user can no longer mark a project in favorite. This commit overrides the standard widget `boolean_favorite` for project to make sure the widget is always editable if the field is not in readonly. task-4041969 ## [FIX] lunch: allow employee to save as favorite a product in lunch Before this commit, the current user could have no access to lunch app to add/edit product, etc. Since the user cannot edit `lunch.product` model, he can no longer save as favorite a product since a recent bug fix (https://github.com/odoo/odoo/pull/168464) to ensure the button is in readonly when the field or the record is in readonly. This commit makes sure the user can always save as favorite even if the record is readonly for the user since the user just has to choose what he would like to eat during lunch break and so he just needs to select and save as favorite. task-4041969