Monday, May 3, 2021
4 changes · master
Enhancements to existing features
The web interface can now load complete groups of templates in one request instead of fetching individual files. This improves efficiency for parts of Odoo that load on demand and ensures template customizations are applied consistently.
Original PR description
Previously, lazy-loading xml templates was only possible by fetching the xml file directly, this meant that it was impossible to lazy-load an entire bundle's templates with a single request. Additionally, requesting the xml files directly meant that no inheritance was applied, causing the need for a separate inheritance system using t-jquery on the client-side. This commit alters the /web/webclient/qweb route so that it now takes an optional bundle id, meaning that it is now possible to lazy-load the xml from arbitrary bundles. task-2497943
Project configuration screens were made easier to use with clearer labels, better field placement, and updated helper text for stages and tags. These changes help users manage task stages and categorize work more efficiently, while also cleaning up unused styling.
Original PR description
Purpose of the task is to do a generic UX improvement in project Specification: -------------- 1) Stages(project.task.type) * List view: - move the 'folded in kanban' field to the right of the…
Purpose of the task is to do a generic UX improvement in project Specification: -------------- 1) Stages(project.task.type) * List view: - move the 'folded in kanban' field to the right of the project_ids one - remove the description field from the list view - make the list view editable in batch * Form view: - rename 'stage name' into 'name' - move the sequence field below the 'rating email template' one - change the copy of the tooltips to: "At each stage, employees can block tasks or mark them as ready for the next step. You can customize here the labels for each state." - the tags should be colored according to the project's color - reduce the space in between the icons and the name of the states - add some space in between the legend_done field and the description - when creating a new mail template, set 'project.task' as model_id of the template * move the 'Stages' menu into below the 'Projects' one * add the project_ids field to the kanban view * search: rename 'Tasks Stages' into 'Name' 2) Tags(project.tags): - configuration > tags menu: change the helper to: "Tags are perfect for categorizing your tasks." - add an optional list view -> only the color field should be optional and displayed by default - new tags should be created at the top of the list - Also removed some of the unused(deprecated) css which are not applied anywhere in the project. TaskID: 2508642
This change improves how Odoo Mail processes automatic field updates so required-field checks happen at the right time. It reduces false validation errors and avoids unnecessary checks on records removed during the same update cycle, making mail-related interactions more reliable.
Original PR description
There is currently a limitation with required fields because an "on change" compute might trigger the check for "required" before all the actual computes have been done, leading to the required field check incorrectly failing. The main goal is to ensure the "on change" computes are done after all the other computes and after the check for required fields. A check has also been added to ensure no "real" compute can trigger update cycle side-effects anymore. Opportunity is also taken to prevent from checking for required fields on a record that was deleted as part of the same update cycle. Somewhat part of task-2278551
Odoo’s internal registry setup was optimized so servers can start faster, especially when many modules are installed. The change reduces repeated setup work across registries and improves bootstrapping time, while keeping behavior largely unchanged for business users.
Original PR description
This proposes a new implementation of * the "discovery" of fields on a given model; * the setup of fields; * the sharing of fields across registries. This new implementation makes the registry…
This proposes a new implementation of * the "discovery" of fields on a given model; * the setup of fields; * the sharing of fields across registries. This new implementation makes the registry loading faster. Our benchmark is two registries with 296 modules (all community modules). Both registries have the same models, so we can see how sharing across registries can save time and/or memory. Here are time measurements for loading both registries (from scratch): Time | before | after | difference ---|---|---|--- Loading Odoo modules | 1176ms | 1339ms | +14% Loading registry 1 | 2042ms | 1067ms | -48% Loading registry 2 | 990ms | 970ms | -2% As we can see, there is some extra work done when loading Odoo modules, but this extra work is done once for all registries using those modules. However, this price is largely compensated by the speedup when loading a registry. Notice also that the net time to load a registry no longer depends whether other registries are present in the server. Overall, the loading of the first registry goes from 3218ms to 2406ms, which is 25% faster. In other words, the bootstrapping time of a server is smaller.