Monday, May 3, 2021
8 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
When an individual contact is linked to a company but has no company image set, the contact card now shows a company-style placeholder instead of a generic camera icon. This makes company-related contacts easier to recognize visually and improves consistency in the contact overview.
Original PR description
taskid: 2491161 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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.
The mail app now handles thread viewer updates through each related model rather than relying on many shared dependencies. This makes the thread viewing experience easier to maintain and adapt across different areas of Odoo, with minimal direct impact on end users.
Original PR description
Instead of thread viewer having many dependencies, this allows models "having the thread viewer feature" to keep their own logic for themselves. The "create or update" part has to be done manually in this case (as opposed to using "insert") because thread viewer has no clear identifying data, since it would depend on which model is using it in the first place.
This update supports faster setup of core system components by making some internal field behavior explicit. It helps improve reliability during system startup and module loading, with no expected day-to-day workflow changes for users.
Original PR description
Companion of https://github.com/odoo/odoo/pull/69924.
The Helpdesk stage form now aligns its legend fields more consistently, matching the layout used in project stages. This makes the configuration screen cleaner and easier for users to read without changing any underlying helpdesk behavior.
Original PR description
Currently, in the helpdesk stages legend_* fields are not properly aligned. so in this commit, align the legend fields on helpdesk stage same as aligned in the project stages. TaskID: 2508642
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.