Daily updates from Odoo
Navigate
Branch
Thursday, July 27, 2023
19 changes
Enhancements to existing features
This update replaces older internal JavaScript reference names with the current module naming approach across several Odoo apps. It is mainly a behind-the-scenes cleanup that improves maintainability and reduces future upgrade friction, with no intended change to day-to-day user workflows.
Original PR description
Description of the issue/feature this PR addresses: Remove all the aliases in the odoo-module of JS files and fix all the imports
Rental sales now update related product details more efficiently in a single operation. This streamlines the behind-the-scenes handling of rental order data and helps keep the experience reliable without changing user workflows.
Original PR description
With the PR 129507 in community, you can update x2m fields using the record.update function. This allows us to update several fields, including x2m fields, in a single call to update.
Resolved issues and error corrections
The accounting view for deferred moves no longer shows a summed total at the bottom of the list in this specific context. This avoids giving users a misleading financial figure when reviewing deferral entries linked to a move.
Original PR description
When viewing the list of deferral moves for a move, it adds up the totals of the deferral moves at the bottom of the list, which seems misleading. With this change we remove that total in this specific context. [task-3441340](https://www.odoo.com/web#id=3441340&menu_id=4720&cids=1&action=333&active_id=967&model=project.task&view_type=form)
This fixes an issue that prevented users from creating new employee appraisals. The appraisal process now works again after being aligned with a recent system change.
Original PR description
The override of `read()` in hr.appraisal was adapted to the changes introduced in #114024.
Code cleanup and technical improvements
This internal cleanup changes how VoIP call updates refresh related conversation information, routing the process through the VoIP communication system. It should help keep the feature easier to maintain without changing day-to-day user workflows.
Original PR description
Part of task-3265211 https://github.com/odoo/odoo/pull/129583
The Point of Sale customer and payment screens were adjusted to stay compatible with recent platform updates. This helps keep localized POS workflows, including Chilean and Mexican e-invoicing and due-settlement payments, working smoothly after the refactor.
Miscellaneous changes
This PR fixes multiple things: **1. Default deferred settings values not set** Currently, when we install the Accountant module from scratch, there are no default deferred settings set. We should have the same behaviour as when installing a CoA: these settings should have default values. This commit fixes this by calling the loading of these settings in the Accountant post init too. **2. Prevent deferred start/end date from being changed if the line is linked to already deferred mov
Original PR description
This PR fixes multiple things: **1. Default deferred settings values not set** Currently, when we install the Accountant module from scratch, there are no default deferred settings set. We should…
This PR fixes multiple things: **1. Default deferred settings values not set** Currently, when we install the Accountant module from scratch, there are no default deferred settings set. We should have the same behaviour as when installing a CoA: these settings should have default values. This commit fixes this by calling the loading of these settings in the Accountant post init too. **2. Prevent deferred start/end date from being changed if the line is linked to already deferred moves** Steps to reproduce: - Create invoice with a deferred line - In Studio, add the Start/End dates to the journal item list view - Modify the Start/End date of a line linked to a posted (i.e. already deferred) move This causes the deferred moves to be inconsistent with the new selected dates. Therefore, we now prevent this by making the field readonly if a deferred move exists. **3. Reset the deferred start/end dates if incompatible account** Steps to reproduce: - Create an invoice with one line - Set Account = 600000 Expense - Set a deferred start date -> Problem 1: the deferred start date is not reset - Set a deferred end date -> Problem 2: the deferred start date is reset but not the end date Both should be reset when the account of the line is not compatible with the document type. task-id 3439208 Forward-Port-Of: odoo/enterprise#44664 Forward-Port-Of: odoo/enterprise#44561
When we have default taxes set up for an account, we don't want the deferral entries to apply these default taxes since that would impact incorrectly impact our tax report. We already fixed this issue for the automatic deferral method in 821e0e0af817d707cfe7729c463c78ef39a0ee35, but we forgot to adapt the manual method. This commit applies the same fix to the manual method. [task-3441167](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=for
Original PR description
When we have default taxes set up for an account, we don't want the deferral entries to apply these default taxes since that would impact incorrectly impact our tax report. We already fixed this issue for the automatic deferral method in 821e0e0af817d707cfe7729c463c78ef39a0ee35, but we forgot to adapt the manual method. This commit applies the same fix to the manual method. [task-3441167](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form&id=3441167) Forward-Port-Of: odoo/enterprise#44641
When we have our deferred method set to "Manual & Grouped" and we have a move that needs to be deferred, but is still in draft, we can show the deferred report with the option "Show Draft entries". If we do so, and we generate the deferral moves from that report, it will also generate deferral moves for the draft moves included in the report. We don't want that. This change makes sure that deferrals are never created for draft moves. [task-3441779](https://www.odoo.com/web#id=3441779&me
Original PR description
When we have our deferred method set to "Manual & Grouped" and we have a move that needs to be deferred, but is still in draft, we can show the deferred report with the option "Show Draft entries". If we do so, and we generate the deferral moves from that report, it will also generate deferral moves for the draft moves included in the report. We don't want that. This change makes sure that deferrals are never created for draft moves. [task-3441779](https://www.odoo.com/web#id=3441779&menu_id=4720&cids=1&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44679
This commit add a small indicator in the spreadsheet's control panel to indicate if the user's locale is different from the spreadsheet's. Task: [3389491](https://www.odoo.com/web#id=3389491&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44038
Original PR description
This commit add a small indicator in the spreadsheet's control panel to indicate if the user's locale is different from the spreadsheet's. Task: [3389491](https://www.odoo.com/web#id=3389491&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44038
The method _common_custom_unfold_all_batch_data_generator used to generate a static dictionary according to the expressions loaded in `data/aged_partner_balance.xml`, however, it was not possible to add new expressions due to the dictionary generation couldn’t be inherited. Proposed solution: Creating a new method that generates and returns a dictionary. This improvement allows us to inherit it and add new keys according to new expressions. Forward-Port-Of: odoo/enterprise#44494 Forward-P
Original PR description
The method _common_custom_unfold_all_batch_data_generator used to generate a static dictionary according to the expressions loaded in `data/aged_partner_balance.xml`, however, it was not possible to add new expressions due to the dictionary generation couldn’t be inherited. Proposed solution: Creating a new method that generates and returns a dictionary. This improvement allows us to inherit it and add new keys according to new expressions. Forward-Port-Of: odoo/enterprise#44494 Forward-Port-Of: odoo/enterprise#39838
Improve low-level checks of recipients in mail asserts. Sometimes 'email_to' cannot be easily deduced from given input (partners, records customers, ...) when some record -> email transformations are involved e.g. when dealing with multiple emails input, double encapsulation, ... See community PR for more details. Task-3438381 (TestMail: backport tools) Prepares Task-2612945 (Mail: Defensive email formatting) Forward-Port-Of: odoo/enterprise#44615 Forward-Port-Of: odoo/enterprise#44533
Original PR description
Improve low-level checks of recipients in mail asserts. Sometimes 'email_to' cannot be easily deduced from given input (partners, records customers, ...) when some record -> email transformations are involved e.g. when dealing with multiple emails input, double encapsulation, ... See community PR for more details. Task-3438381 (TestMail: backport tools) Prepares Task-2612945 (Mail: Defensive email formatting) Forward-Port-Of: odoo/enterprise#44615 Forward-Port-Of: odoo/enterprise#44533
Addition of the 3 UoMs (Service Unit, Activity, Job) default UNSPSC category for the Mexican localisation. task-3392056 Forward-Port-Of: odoo/enterprise#44267 Forward-Port-Of: odoo/enterprise#43524
Original PR description
Addition of the 3 UoMs (Service Unit, Activity, Job) default UNSPSC category for the Mexican localisation. task-3392056 Forward-Port-Of: odoo/enterprise#44267 Forward-Port-Of: odoo/enterprise#43524
Active field of data_merge.record is computed from: not (record.is_deleted or record.is_discarded) opw-3337867 Description of the issue/feature this PR addresses: Scheduled action: data cleanup will delete data_merge group each day based on some rules If the record in group has been ignored, the cleanup browsing will ignore it and so delete the group as it's empty. Data cleanup generation run every day too Current behavior before PR: Ignored record are regenerate after a cleanup
Original PR description
Active field of data_merge.record is computed from: not (record.is_deleted or record.is_discarded) opw-3337867 Description of the issue/feature this PR addresses: Scheduled action: data cleanup will delete data_merge group each day based on some rules If the record in group has been ignored, the cleanup browsing will ignore it and so delete the group as it's empty. Data cleanup generation run every day too Current behavior before PR: Ignored record are regenerate after a cleanup Desired behavior after PR is merged: Ignored record are not regenerate after a cleanup --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#42474
In order to add the push-notification capability to the PWA in enterprise, the enterprise webclient needs to listen for changes in permissions. The listener was not correctly cleared on destroy, which caused tests that use the enterprise webclient to leak the entire owl application and its corresponding DOM (this was mostly visible in studio tests) This commit fixes that by removing the event listener when the webclient is destroyed. community: https://github.com/odoo/odoo/pull/129714 For
Original PR description
In order to add the push-notification capability to the PWA in enterprise, the enterprise webclient needs to listen for changes in permissions. The listener was not correctly cleared on destroy, which caused tests that use the enterprise webclient to leak the entire owl application and its corresponding DOM (this was mostly visible in studio tests) This commit fixes that by removing the event listener when the webclient is destroyed. community: https://github.com/odoo/odoo/pull/129714 Forward-Port-Of: odoo/enterprise#44600
Clean context and add a way to whitelist default fields. Forward-Port-Of: odoo/enterprise#44633 Forward-Port-Of: odoo/enterprise#44466
Original PR description
Clean context and add a way to whitelist default fields. Forward-Port-Of: odoo/enterprise#44633 Forward-Port-Of: odoo/enterprise#44466
This commit fixes 2 issues conerning carryover popover in accounting reports: a) To reproduce: - Activate developer mode (because props validation only occurs when activated) - Open a tax report with an amount on a line that must be carried forward (example: French tax report at line 27) - Press the little circle on the left side of the amount Result: A traceback is raised, due to incorrect props value b) To reproduce - Activate developer mode - Settle a tax report (closing ent
Original PR description
This commit fixes 2 issues conerning carryover popover in accounting reports: a) To reproduce: - Activate developer mode (because props validation only occurs when activated) - Open a tax report with an amount on a line that must be carried forward (example: French tax report at line 27) - Press the little circle on the left side of the amount Result: A traceback is raised, due to incorrect props value b) To reproduce - Activate developer mode - Settle a tax report (closing entry) with an amount that must be carried forward to the next tax report - Open the tax report of the next period - Click on the popover of the receiving line - Click on the 'View Carryover Lines' Result: A traceback is raised Forward-Port-Of: odoo/enterprise#44541 Forward-Port-Of: odoo/enterprise#43445
Since the rewrite of Studio in Owl, the aggregate option was unavailable on float fields in list views. This commit brings back the possibility to edit this option on the field of those types. A test has been edited to verify the presence of the option when using studio on a list view on monetary and float fields as well. Finally, dead code related to the aggregation behavior has been removed from list_editor_sidebar.js task-3433586 Forward-Port-Of: odoo/enterprise#44548 Forward-Port-O
Original PR description
Since the rewrite of Studio in Owl, the aggregate option was unavailable on float fields in list views. This commit brings back the possibility to edit this option on the field of those types. A test has been edited to verify the presence of the option when using studio on a list view on monetary and float fields as well. Finally, dead code related to the aggregation behavior has been removed from list_editor_sidebar.js task-3433586 Forward-Port-Of: odoo/enterprise#44548 Forward-Port-Of: odoo/enterprise#44531
Before this commit, the `project_enterprise_tour` has a step to check allow billable during the project creation, this step can only be done if `sale_project` module is installed but since `project_enterprise` does not depend on that module the tour will fail if only project_enterprise is installed. This commit removes the step to check allow billable in project form view when a project is created since in `project_enterprise` module `allow_billable` field in `project.project` model does not
Original PR description
Before this commit, the `project_enterprise_tour` has a step to check allow billable during the project creation, this step can only be done if `sale_project` module is installed but since `project_enterprise` does not depend on that module the tour will fail if only project_enterprise is installed. This commit removes the step to check allow billable in project form view when a project is created since in `project_enterprise` module `allow_billable` field in `project.project` model does not exist. Forward-Port-Of: odoo/enterprise#44406