Sunday, September 18, 2022
7 changes · master
Enhancements to existing features
Website pages now package shared frontend resources more directly, reducing the number of main JavaScript files loaded by public pages. This should help improve page speed scores and make website styling more consistent with each site's custom theme settings.
Original PR description
This PR is a first step towards a potential deletion of the assets_common bundle, although that step would need more work, specs and discussions as some layouts kinda only use the assets_common…
This PR is a first step towards a potential deletion of the assets_common bundle, although that step would need more work, specs and discussions as some layouts kinda only use the assets_common bundle (some take the full assets_common but parts of the assets_backend one for example). The main goal of this commit is to have the assets_frontend bundle directly include the "common" files we need. As a first step, this commit only blindly duplicates them all into assets_frontend (without removing the potentially useless ones). The goal is to have those advantages: - Reaching a frontend page only calls two main JS files (one normal and one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This may help reach a better google page speed (which is becoming more and more strict). - The frontend CSS is built as one: the common SCSS which was using bootstrap variables, or even Odoo-based SCSS added by mistake in common instead of both backend and frontend is now computed with the right bootstrap customizations. E.g. the tempusdominus datetimepickers use bootstrap grays... after this PR, they use the right grays as customized by the user on the website. It was also chosen to not have a common "sub-asset" which is included in assets_frontend. Making assets_frontend completely independent makes sense (as it probably will for other "main" asset bundles): we can focus on adding the files each layout needs without the need of worrying if it impacts unrelated layouts. Sub-assets (when not strictly necessary) is also a source of errors: extending the "main" bundle instead of the right sub-asset it may use (like it was the case with the sub-assets of assets_common: _assets_common_scripts and _assets_common_styles as explained in the previous commit). So this is indeed a small drawback of not factorizing the code for the inclusion of "common" files in bundles but it seems more explicit and easier to maintain that way. Note that adding "common" file is not the most common usecase anyway, apps generally only need files in backend or frontend. The __manifest__ declaration will also likely evolve in more and more uses of wildcards to match entire directories. In the future, adding "common" web-app files in both backend, frontend and other "main" bundles could just be about one line duplicated into each bundle.
This update reorganizes shared frontend asset files so they are included directly where they are used. It should have no visible effect for users, but helps keep the platform structure simpler and easier to maintain.
Original PR description
See community commit for details.
Resolved issues and error corrections
Form labels are now matched to fields using only visible view identifiers instead of internal technical IDs. This prevents labels from appearing blank or attaching to the wrong field, especially when forms contain repeated field names.
Original PR description
with its label Before this commit, when compiling the field to link the field with a previously found label, to search, we used in order : the 'id' (encoded on the arch), the 'field_id' (an internal technical ID), the 'name' (also in the arch). The issue with this is that the "field_id" is a technical id and shouldn't be used, to search the label. Now, we only search for the 'id' and the 'name'.
Miscellaneous changes
Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon. Forward-Port-Of: odoo/odoo#100259
Original PR description
Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon. Forward-Port-Of: odoo/odoo#100259
Records now keep the information needed by views while they are loading, instead of being temporarily emptied. This prevents kanban views from crashing during refreshes and makes record loading more reliable for users.
Original PR description
Before this PR, when a record from a relational model would start to load, it would empty its `data` object. The issue is that a rendering process can be initiated right after a record started loading. In kanban views, this causes a crash since all records are always assumed to contain values in their data objects. This PR takes care to only clean strictly unwanted data when loading a record instead of removing all the values, ensuring that records always contain data. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Since https://github.com/odoo/odoo/pull/76722, it is possible to cancel an approved time off. However, the calendar event created when the leave is validated is not archived when the leave is cancelled. This commit archives the calendar event when the leave is cancelled. task-2965754 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
Original PR description
Since https://github.com/odoo/odoo/pull/76722, it is possible to cancel an approved time off. However, the calendar event created when the leave is validated is not archived when the leave is cancelled. This commit archives the calendar event when the leave is cancelled. task-2965754 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 Forward-Port-Of: odoo/odoo#99731
In hr_holidays, the banner disappears when the number of days taken is more than the days allocated. Also, the count of the days is based on all existing allocations. This commit fixes the banner by allowing to display negative days remaining when there are more days taken than days allocated. It also fixes the count of the days by couting days only for active allocations. task-2983188 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior
Original PR description
In hr_holidays, the banner disappears when the number of days taken is more than the days allocated. Also, the count of the days is based on all existing allocations. This commit fixes the banner by allowing to display negative days remaining when there are more days taken than days allocated. It also fixes the count of the days by couting days only for active allocations. task-2983188 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 Forward-Port-Of: odoo/odoo#100446 Forward-Port-Of: odoo/odoo#100216