Daily updates from Odoo
Sunday, February 25, 2024
4 changes · 17.0
Resolved issues and error corrections
This fix resolves a crash that occurred when displaying planning slots that fit within a single time interval (such as a single day in the weekly view). The system was attempting to create split indicators (scissors) between intervals, but when a slot only occupied one interval, it would try to create an invalid array, causing an error. The fix simply skips rendering split indicators for slots that cannot be split further.
Original PR description
Closes Odoo Helpdesk Ticket 3.705.995 **Error description** - In the File enterprise/planning/static/src/views/plnaning_gantt/planning_gantt_renderer.xml in the template…
Closes Odoo Helpdesk Ticket 3.705.995 **Error description** - In the File enterprise/planning/static/src/views/plnaning_gantt/planning_gantt_renderer.xml in the template planning.PlanningGanttRenderer.Pill the intention is to add the split scissor - There should be one scissor between each interval, in our weekly example between each day. This makes n-1 scissors with n the total of interval a planning slot overlaps - It is possible that there exist slots which do only overlap the current timespan with one time unit. For example only one day in the week view (starting at sunday) - For this slot, the number of scissors would be 0 (n-1) - We then ge an error on line 19 on the initialisation of a new Array with length one: RangeError: Invalid array length **Suggested Solution** - Slots which are exactly in one interval (for example in one day in the week view) can't be split any more. They are already in the smallest unit. - I suggest to not render any scissors for these slots - This can be done by checking the length of n before the foreach loop
Fixed the planning module's interactive tour to work properly even when demo data is not installed. Previously, the tour would get stuck at the Publish & Send step because no shifts were assigned to employees. The fix adds test data setup to ensure the tour can complete successfully in all scenarios.
Original PR description
Currently if demo data is not installed, the planning tour will be blocked at the Publish & Send part since there are no shift assigned to an employee. To allow the tour to run even without any demo data, we need to add an employee and make sure that the user assigns a shift to this employee This should be forward ported from 15.0 to master on every stable version Task-3617611 Forward-Port-Of: odoo/enterprise#57260 Forward-Port-Of: odoo/enterprise#53411
Fixed a bug in the planning module's gantt view where the split tool (used to divide tasks across multiple days) was incorrectly positioned when tasks extended before the displayed week. The fix ensures the tool only processes tasks that are actually visible in the current view, preventing errors and improving the user experience when viewing scheduled work.
Original PR description
Before this commit, when the gantt view displays the current week, let's say from `2024-18-02` to `2024-24-02` and the planned dates of one pill is: - `start_datetime`: `2024-17-02 16:00:00` - `end_datetime`: `2024-18-02 00:00:00` (the end datetime of the pill should be the first column displayed in the gantt view), a traceback is occurred because the pill will not be displayed in the gantt view and so the grid column for that pill will be 0 and since the split tool uses the grid column for each pill to place the different scissor to enable the split tool for the pills displayed on more than one column in the gantt view. This commit makes sure the split tool will skip the pill with column less than 1 to be sure `pill.grid.column[0] - 1` uses to create a array will not be less than 0. opw-3705995 closes #55807
This fix prevents the website editor from crashing when users try to add picture snippets that reference broken or missing image links (404 errors). Instead of crashing, the system now gracefully handles these cases by displaying a placeholder image, allowing users to continue editing their website without interruption.
Original PR description
Commit [1] introduced some code that relied on a cache we currently have for processed** images. In case of 404, that cache is not filled... and relying on it thus crashes. This commit circles around…
Commit [1] introduced some code that relied on a cache we currently have for processed** images. In case of 404, that cache is not filled... and relying on it thus crashes. This commit circles around the issue by taking profit of [2] which now forces `loadImage` to load a placeholder image in case of a 404. This makes sure that in case of a 404 during the initial call to `loadImage`, the rest of the stack works with the loaded placeholder image. **Note: the current cache is not filled at the `loadImage` level, but later when processing the fetched image. This should be changed in the future (a task has been created). See [3] and [4] which are example of unwanted 404 images due to other issues, which allowed to discover this bug to fix here. Steps to reproduce: - Go on the `website.s_picture_default_image` ir.attachment form view - Change the URL value to a relative path that does not exist - Go on a website page and edit - Drop the "Picture" snippet => Crash => After this fix, no crash but you can also edit the image if you were able to click on it, it would use the placeholder image as source. [1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f [2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d [3]: https://github.com/odoo/odoo/pull/155015 [4]: https://github.com/odoo/design-themes/pull/767 Related to opw-3693055 and others (see [3] and [4]). Forward-Port-Of: odoo/odoo#155097