Wednesday, January 8, 2025
6 changes · saas-17.2
Resolved issues and error corrections
This fix prevents Odoo Studio's systray menu from crashing when it refreshes while a page with multiple actions is still loading. It improves reliability for users opening Studio from complex URLs, avoiding an interruption during navigation.
Original PR description
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
Users working through project sharing can now update planned dates on tasks without encountering an error. This prevents interruptions for external or portal collaborators and keeps shared project workflows running smoothly.
Original PR description
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305
Map views for contacts now correctly display the name of a related group, such as the salesperson, instead of showing "None". This makes grouped map results easier to understand and helps users navigate customer locations more efficiently.
Original PR description
Before this commit, for map views on res.partner (which have attribute res_partner = id), if the user group by a relational field (X2many, many2one), the name of the group is "None" ### Steps to reproduce: Contacts > Map view in the search bar, group by "Salesperson" On the left side of the map view, the group name is "None" ### Expected Name of partner salesperson should be visible instead of "None" original PR : #74205
This fixes a Point of Sale settings issue where the preparation display stayed enabled after managers turned it off. Businesses can now disable that display when self-ordering is not active, avoiding unwanted preparation screen behavior.
Original PR description
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. (forward port of https://github.com/odoo/enterprise/commit/d3606d5a99ba7328cce164c0c16ff594d7639f4a) opw-4225668 X-original-commit: https://github.com/odoo/odoo/commit/2d753a90d0612b35d9d012574915d2e6bb754b1f
This fix ensures the point of sale settlement process uses the already calculated order total including tax. It helps avoid mismatches when customers settle unpaid orders, improving billing accuracy at checkout.
Original PR description
Related: https://github.com/odoo/odoo/pull/174184
Fixes an issue where grouping journal items by Internal Group could cause an error instead of showing results. This makes financial reporting views more reliable for users organizing accounting entries.
Original PR description
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr