Daily updates from Odoo
Tuesday, July 16, 2024
4 changes · master
Enhancements to existing features
Gantt scheduling views are now loaded only when needed instead of during initial app startup. This should improve loading performance for users who do not immediately open scheduling screens, while keeping gantt functionality available across affected business apps.
Original PR description
We make the gantt view and its extensions to be lazy loaded. locs (js,xml,scss) added in "web.assets_backend_lazy" ~ 8500. Task ID: `3546321`
Report documents across payroll, accounting follow-up, field service, sales, point of sale, and multiple localization areas have been adjusted to align with the new standard document layouts. This improves visual consistency while preserving special payroll and local statutory report formats where required.
Original PR description
This PR follows the changes made in community to introduce and review the report documents layouts. - Adapting tables to community changes - Fixing xpaths - Disabling layout design on payroll report Community PR: https://github.com/odoo/odoo/pull/169512 task-3628644
The report editor now lets users add or remove columns in complex report tables that previously could not be edited this way. This makes customizing business reports in Studio easier while preserving current limitations around row editing.
Original PR description
The report editor edits raw qweb. In this setting, tables can contain illegal nodes with regard to html spec. So we need to convert those tables into something else, that is, as simple div-like elements displayed as flex. Before this commit, it was not possible to add/remove columns. This commit proposes a solution to this. Note that, given the use cases, removing/adding rows is still impossible because we assume tables of that type are doing a `t-foreach` in the row dimension. task-3940106
Features or functions removed from Odoo
This change rolls back a previous attempt to share common sales and purchase order logic because it added complexity and limited how each process can evolve. It also restores related naming changes to avoid conflicts, keeping sales and purchasing behavior separate and more stable.
Original PR description
In the end the feature as implemented in the original PR is not desired/correct and the mixin is also not wanted due to it adding more complexity than removing. Additionally, we want to keep the SO and PO functionality/evolution separate so moving their apparently common fields/methods into a mixin was a mistake. Therefore we revert the mixin and all of the renaming refactorings that also came out of the PR since they depend on the mixin and we do not want to handle the complexity of fixing the conflicts.