Friday, November 4, 2022
48 changes · master
Enhancements to existing features
The CRM leads and opportunities list is now less cluttered by hiding phone and company columns by default. Users can still show these fields when needed, but the everyday view is easier to scan and work with.
Original PR description
At the moment, the tree view is quite dense. In order to ease its use, make company and phone fields optional and hidden by default. This is done for crm.leads as both leads and opportunities. Task-3053159
Product option restrictions are now defined alongside the products they affect, instead of being split across the sales module. This reduces the risk of installation failures or data inconsistencies when modules are installed in different orders.
Original PR description
Following recent changes in stable deleting/archiving product variants forbidden by attributes exclusions, installing some modules after the sale app failed because the product `product_product_4d` specified in `product` was deleted by the attributes exclusions of the `sale` module. This has been fixed in stable by removing all references to this xml_id. Nevertheless, this bug showed us that the definition of attributes exclusion for a product in another module than the one creating it is a bad idea, as it modifies what's allowed or not with that product, leading to potential database inconsistencies. This commit moves the exclusions targeting products from the `product` module to the `product` module, to reduce the risks of other modules using/referencing the deleted/modified products in a way conflicting with the exclusions.
Resolved issues and error corrections
Clipboard fields now stay visible even when they have no content, so users can edit them instead of seeing a missing field. This improves form usability and prevents issues when empty text values are handled by the copy button.
Original PR description
**Issue:** When a copy clipboard field is empty, there is no way to edit it because the Field component is not shown. This issue can be reproduced using any type of copy clipboard field: -…
**Issue:** When a copy clipboard field is empty, there is no way to edit it because the Field component is not shown. This issue can be reproduced using any type of copy clipboard field: - CopyClipboardChar - CopyClipboardText - CopyClipboardURL Check the following video for illustration: https://youtu.be/CTzqJRtwqv0 **Solution:** This PR proposes a fix of *always* showing the copy clipboard field (together with the copy button) even if the content is empty. For illustration, check: https://youtu.be/jMM7zn_mFCU **Notable changes:** - The modified tests were using a wrong class name. But since they were asserting the "non-existence" of the copy button, they were working. - We are casting null text field to empty string (just like char field) so that we avoid crash (in dev mode) when passing a "boolean" as 'content' props to the 'CopyButton' component. This is asserted in the augmented test case where we also try to render an empty text field. TASK-ID: 2861388 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, the sale_timesheet tour sometimes fails because it cannot click on the save button. Since the always edit feature, the form view is automatically saved when the user leaves the view, so it is now not necessary to click on the save button and then leave the form view. This commit removes the steps in which they simulate the user clicks on the save button to avoid any indeterminate errors when that tour is launched. Forward-Port-Of: odoo/odoo#104159
Original PR description
Before this commit, the sale_timesheet tour sometimes fails because it cannot click on the save button. Since the always edit feature, the form view is automatically saved when the user leaves the view, so it is now not necessary to click on the save button and then leave the form view. This commit removes the steps in which they simulate the user clicks on the save button to avoid any indeterminate errors when that tour is launched. Forward-Port-Of: odoo/odoo#104159
steps to reproduce the bug: - Create a service product with "invoicing policy" set to "Based on timesheet" and "create on order" set to "project and task" - Create and invoice with the product and confirm it - Type in some hours on timesheets for the invoice - Go Project -> Project update of the project, The margin value is incorrect Solution: As the cost are always negative, changed the operation of the calculation to have the good value. opw-3029869 Forward-Port-Of: odoo/odoo#104052
Original PR description
steps to reproduce the bug: - Create a service product with "invoicing policy" set to "Based on timesheet" and "create on order" set to "project and task" - Create and invoice with the product and confirm it - Type in some hours on timesheets for the invoice - Go Project -> Project update of the project, The margin value is incorrect Solution: As the cost are always negative, changed the operation of the calculation to have the good value. opw-3029869 Forward-Port-Of: odoo/odoo#104052
Before this commit, the f3974bea4bf039adfbc12cefbf0475573cbfc4b2 adds the project as filter in the search view when the user wants to add a subtask on a task in the form view. This feature has been broken due to a change on the search view. The main search has no longer the display_project_id field, only the one inherited the main one has that field. (commit da868d28e2f1268acf0ee413f04ebf3554182249) This commit changes the search view to use to correctly have the project of the parent task as
Original PR description
Before this commit, the f3974bea4bf039adfbc12cefbf0475573cbfc4b2 adds the project as filter in the search view when the user wants to add a subtask on a task in the form view. This feature has been broken due to a change on the search view. The main search has no longer the display_project_id field, only the one inherited the main one has that field. (commit da868d28e2f1268acf0ee413f04ebf3554182249) This commit changes the search view to use to correctly have the project of the parent task as default project when the user wants to search a subtask to add on the task displayed in the form view. Forward-Port-Of: odoo/odoo#104791
Prior to this commit and since odoo/odoo#94144, a default project_id is provided event for non timesheets. This commit fixes this issue by setting a context key in the `account.analytic.line` actions that are related to timesheets and by setting the default project_id only when this key is set to `True`. This commit also removes `encoding_uom_id` from 'default_get' as it is any computed as the field is compute (not stored). --- I confirm I have signed the CLA and read the PR guideline
Original PR description
Prior to this commit and since odoo/odoo#94144, a default project_id is provided event for non timesheets. This commit fixes this issue by setting a context key in the `account.analytic.line` actions that are related to timesheets and by setting the default project_id only when this key is set to `True`. This commit also removes `encoding_uom_id` from 'default_get' as it is any computed as the field is compute (not stored). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104820
Steps: - Open studio in any form view - Add Binary Field - Close Studio - Upload a file in the previously added binary field - We can't download it because of always edit This commit adds a new download button near edit and clear button opw-3028094 Forward-Port-Of: odoo/odoo#104143
Original PR description
Steps: - Open studio in any form view - Add Binary Field - Close Studio - Upload a file in the previously added binary field - We can't download it because of always edit This commit adds a new download button near edit and clear button opw-3028094 Forward-Port-Of: odoo/odoo#104143
- Create Malaysia Accounting localisation task-2870449 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#92729
Original PR description
- Create Malaysia Accounting localisation task-2870449 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#92729
**Description of the issue/feature this PR addresses:** Duplicated values in the invoice report. Terms and Conditions, Fiscal Position, Incoterms and QR Code **Current behavior before PR:** Duplicated values in invoice report. **Desired behavior after PR is merged:** Remove duplicated values --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103878
Original PR description
**Description of the issue/feature this PR addresses:** Duplicated values in the invoice report. Terms and Conditions, Fiscal Position, Incoterms and QR Code **Current behavior before PR:** Duplicated values in invoice report. **Desired behavior after PR is merged:** Remove duplicated values --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103878
Prior to this commit get_paperformat function in ir_actions_report.py file was trying to get a paperformat_id of an empty report and as there was none was automatically returning company paperformat_id. After this commit said function will try to get a paperformat_id of the report with specific report_ref value. Task-2980708 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100199
Original PR description
Prior to this commit get_paperformat function in ir_actions_report.py file was trying to get a paperformat_id of an empty report and as there was none was automatically returning company paperformat_id. After this commit said function will try to get a paperformat_id of the report with specific report_ref value. Task-2980708 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100199
Description of the issue/feature this PR addresses: When executing the product2bom method it is possible that an active_test context is present in self. This causes the method to consider archived BoMs and resulting in wrong BoM explosion. This happens for example when a delivery is validated and the qty delivered in the sales order lines is recomputed. When exploding the BoMs for kit products, there is an active_test context coming from https://github.com/odoo/odoo/blob/affc9abbcf596e025af0
Original PR description
Description of the issue/feature this PR addresses: When executing the product2bom method it is possible that an active_test context is present in self. This causes the method to consider archived…
Description of the issue/feature this PR addresses: When executing the product2bom method it is possible that an active_test context is present in self. This causes the method to consider archived BoMs and resulting in wrong BoM explosion. This happens for example when a delivery is validated and the qty delivered in the sales order lines is recomputed. When exploding the BoMs for kit products, there is an active_test context coming from https://github.com/odoo/odoo/blob/affc9abbcf596e025af0fd33654af3fca709b2ed/addons/stock_account/models/stock_move.py#L276 Current behavior before PR: When executing the product2bom method and there is an active_test context in self, archived BoMs are considered in the method. Desired behavior after PR is merged: When executing the product2bom method and there is an active_test context in self, archived BoMs are not considered in the method. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104512 Forward-Port-Of: odoo/odoo#100771
The smart buttons were computing the number of aml instead of the number of invoices/bills with the account. We now compute back the number of moves. We also changed it so it is consistent with the view, so it computes the number of moves with move lines that have the distribution instead of the analytic lines with the account. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed th
Original PR description
The smart buttons were computing the number of aml instead of the number of invoices/bills with the account. We now compute back the number of moves. We also changed it so it is consistent with the view, so it computes the number of moves with move lines that have the distribution instead of the analytic lines with the account. 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#103811
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103494
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103494
Related to https://github.com/odoo/enterprise/pull/32020 Add a hook to return the account payment method code. opw-2985984 Forward-Port-Of: odoo/odoo#104600 Forward-Port-Of: odoo/odoo#101904
Original PR description
Related to https://github.com/odoo/enterprise/pull/32020 Add a hook to return the account payment method code. opw-2985984 Forward-Port-Of: odoo/odoo#104600 Forward-Port-Of: odoo/odoo#101904
When the seller is foreign, the Fiscal Regime of the seller must be set to 'RF18', as per: https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/ Task: https://www.odoo.com/web#id=3010849&model=project.task opw-3010849 Forward-Port-Of: odoo/odoo#104780
Original PR description
When the seller is foreign, the Fiscal Regime of the seller must be set to 'RF18', as per: https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/ Task: https://www.odoo.com/web#id=3010849&model=project.task opw-3010849 Forward-Port-Of: odoo/odoo#104780
**Issue:** The aggregate row of the list renderer doesn't take into account the fields with zero values. As a result, average values are not correctly computed. E.g. average of [2, 0] => 2 instead of 1. **Illustration of the issue:** <img width="1479" alt="Screenshot 2022-11-03 at 13 36 52" src="https://user-images.githubusercontent.com/3245568/199722072-13413079-e21b-4e74-ad14-e2cfca0d7d56.png"> **Solution:** Make sure 0s are included in the valid values to aggregate. **Change note:
Original PR description
**Issue:** The aggregate row of the list renderer doesn't take into account the fields with zero values. As a result, average values are not correctly computed. E.g. average of [2, 0] => 2 instead of 1. **Illustration of the issue:** <img width="1479" alt="Screenshot 2022-11-03 at 13 36 52" src="https://user-images.githubusercontent.com/3245568/199722072-13413079-e21b-4e74-ad14-e2cfca0d7d56.png"> **Solution:** Make sure 0s are included in the valid values to aggregate. **Change note:** We took the opportunity to make a simple refactor in the affected test. Instead of asserting contents of the row with multiple strictEquals (one per cell), we use deepEqual to check the cells in the aggregate row. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104829
Even if a many2many field is forcely set to be sortable, it should not be included in the list of custom groupby options if it's an un-stored field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104911 Forward-Port-Of: odoo/odoo#104674
Original PR description
Even if a many2many field is forcely set to be sortable, it should not be included in the list of custom groupby options if it's an un-stored field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104911 Forward-Port-Of: odoo/odoo#104674
Steps to reproduce ================== - Create a BOM - Add a line with a product of type product - Set the quantity to 0 - Save and click on overview -> ServerError: Division by 0 Cause of the issue ================== Lines with a quantity of 0 should be excluded from the computation opw-3053167 Forward-Port-Of: odoo/odoo#104760
Original PR description
Steps to reproduce ================== - Create a BOM - Add a line with a product of type product - Set the quantity to 0 - Save and click on overview -> ServerError: Division by 0 Cause of the issue ================== Lines with a quantity of 0 should be excluded from the computation opw-3053167 Forward-Port-Of: odoo/odoo#104760
Before this commit, when deleting a message, there was a traceback. This was caused by `MessageView/onComponentUpdate` wrongly assuming `MessageView` from a single branching of identifying owner (`messageListViewItemOwner`), when there is another one (`deleteMessageConfirmViewOwner`), specific to when a message is being deleted. As a result, crash came from programming error of accessor on undefined relational field. Task-3055205 Forward-Port-Of: odoo/odoo#104921
Original PR description
Before this commit, when deleting a message, there was a traceback. This was caused by `MessageView/onComponentUpdate` wrongly assuming `MessageView` from a single branching of identifying owner (`messageListViewItemOwner`), when there is another one (`deleteMessageConfirmViewOwner`), specific to when a message is being deleted. As a result, crash came from programming error of accessor on undefined relational field. Task-3055205 Forward-Port-Of: odoo/odoo#104921
**Description of the issue/feature this PR addresses:** prevent opening the form view of report.project.task.user model, currently there is no form view defined for the model and thus when user open the form view, he is getting default form view which is not aligned well. As there is no point of adding a new form view for the model, this pr will prevent user from opening the form view. ****Current behavior before PR:*** As form view is not defined, the current ui is as follows:  **Desired behavior after PR is merged:** Prevent the use from opening the form view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103853
Steps: - Install hr_timesheet - Enable Analytic Accounting - Create a project and create a task - Archive the Project's Analytic Accounting - Open the task and go to the Timesheets page Issue: - Warning message box width is small. Fix: - Provide the proper format of the warning message box. task-3010437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104610
Original PR description
Steps: - Install hr_timesheet - Enable Analytic Accounting - Create a project and create a task - Archive the Project's Analytic Accounting - Open the task and go to the Timesheets page Issue: - Warning message box width is small. Fix: - Provide the proper format of the warning message box. task-3010437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104610
The main motivation for this change is to improve performance of BoM `explode`, which heavily rely on checking the lines to skip. `explode` is also called from product `compute_quantities_dict` which is called multiple times during upgrades. With this fix we improved the running time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16% performance improvement. The goal of `_skip_bom_line` is to check that for each attribute present on the line, at least one value associated to t
Original PR description
The main motivation for this change is to improve performance of BoM `explode`, which heavily rely on checking the lines to skip. `explode` is also called from product `compute_quantities_dict` which…
The main motivation for this change is to improve performance of BoM `explode`, which heavily rely on checking the lines to skip. `explode` is also called from product `compute_quantities_dict` which is called multiple times during upgrades. With this fix we improved the running time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16% performance improvement. The goal of `_skip_bom_line` is to check that for each attribute present on the line, at least one value associated to that attribute must be in the attribute values of the product(*). If none is found then we consider that we can skip the line. The previous implementation was inefficient. It grouped all values by attribute, then checked one by one if at least one value is on the product. In case one attribute does not have any value on the product it skipped the line. The implementation we propose here is to take the intersection of the product and line values, then check that their attributes are the same. The later can be done with a simple length check. In case they are different the line must be skipped. Note that this works because only one value is possible per attribute in a product. Both implementations are equivalent. The second is more efficient because does not branch and relies on (record)set operations. For example, let's consider a product with two attribute values `a` and `b`, and a line with multiple values `a`,`y` for attribute 1, and `z` for attribute 2. ``` Product Line +---+ +-----+ | a | <- same attribute -> | a,y | +---+ +-----+ | b | <- same attribute -> | z | +---+ + ----+ ``` This line must be skipped. The reason is that the value `b` is not among the list `[z]` of values for attribute 2 on the line. The new implementation would get the intersection of attribute values as `[a]` from there the comparison of the attributes will fail because `[a]` has only one attribute while the line has two. Let's consider a second case, where there is no value on the line for attribute 2. ``` Product Line +---+ +-----+ | a | <- same attribute -> | a,y | +---+ +-----+ | b | <- same attribute -> | | +---+ + ----+ ``` This line is not skipped because there is no value for attribute 2 on the line. Therefore the condition(*) per attribute is not violated for this product. The new implementation gets `[a]` as intersection of values, but now the attributes coincide: they are both attribute 1 for the intersection and the line. Finally, ``` Product Line +---+ +-----+ | a | <- same attribute -> | a,y | +---+ +-----+ | | <- same attribute -> | z,w | +---+ + ----+ ``` This line is skipped because none of `[z,w]` are in the product. The new implementation would get again `[a]` as intersection which does not match the attributes on the line. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104976 Forward-Port-Of: odoo/odoo#99047
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#104116
Original PR description
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#104116
Fixes the problem that some syntactic sugar formulas were not updated correctly when changed in the xml of reports. In particular, during upgrade of modules changes were not taken into account. Concerned formulas: `account_codes_formula`, `aggregation_formula`, `domain_formula`. Also fixes error happening when when computing indented formulas (whitespace, tab, end of line). Related: https://github.com/odoo/odoo/pull/104518 Forward-Port-Of: odoo/odoo#104810
Original PR description
Fixes the problem that some syntactic sugar formulas were not updated correctly when changed in the xml of reports. In particular, during upgrade of modules changes were not taken into account. Concerned formulas: `account_codes_formula`, `aggregation_formula`, `domain_formula`. Also fixes error happening when when computing indented formulas (whitespace, tab, end of line). Related: https://github.com/odoo/odoo/pull/104518 Forward-Port-Of: odoo/odoo#104810
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#104988
Original PR description
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#104988
Before this patch, when doing an SMTP connectivity check, Odoo always checked if the current user with their current email address could connect. That was inaccurate because: 1. If the `ir.mail_server` were configured with an email address as `from_filter`, that's going to be the address used to connect with the server always; never your user email. 2. If it were configured with a domain as `from_filter` and your user had an email from another domain, your outgoing emails are going to get w
Original PR description
Before this patch, when doing an SMTP connectivity check, Odoo always checked if the current user with their current email address could connect. That was inaccurate because: 1. If the `ir.mail_server` were configured with an email address as `from_filter`, that's going to be the address used to connect with the server always; never your user email. 2. If it were configured with a domain as `from_filter` and your user had an email from another domain, your outgoing emails are going to get wrapped into that domain (SRS-like). Again, the connectivity check wouldn't be imitating real world connections. After the patch, both situations are taken into account when deciding the outgoing address that's going to be used for testing the connection. This will reduce false negatives when testing connectivity. @moduon MT-1064 OPW-2942814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104417
Name field can return False, which is not compatible with a replace. We therefore fallback on a void string, as already done in various other report names. Related to Task-2868153 (Mail: Allow multi-reports mail templates) Forward-Port-Of: odoo/odoo#104991
Original PR description
Name field can return False, which is not compatible with a replace. We therefore fallback on a void string, as already done in various other report names. Related to Task-2868153 (Mail: Allow multi-reports mail templates) Forward-Port-Of: odoo/odoo#104991
Have the following taxes: - Tax A: 15%, included in price - Tax B: 21%, included in price Create a product P with list price 115 and tax A Have a fiscal positions FPOS configured with: - Detect Automatically checked - Country: Belgium - Map tax on product: A -> B Open a web shop session as guest, add P to cart Go to checkout: Price total will be 115 Fill address details with Belgium address Go to confirmation page Error: Price total will be 100. In the application of fiscal
Original PR description
Have the following taxes: - Tax A: 15%, included in price - Tax B: 21%, included in price Create a product P with list price 115 and tax A Have a fiscal positions FPOS configured with: - Detect Automatically checked - Country: Belgium - Map tax on product: A -> B Open a web shop session as guest, add P to cart Go to checkout: Price total will be 115 Fill address details with Belgium address Go to confirmation page Error: Price total will be 100. In the application of fiscal position the wrong unit price is used opw-2973879 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#104996 Forward-Port-Of: odoo/odoo#101364
- on Ecommerce website Add an item to your cart. - Billing/Shipping info > Stop on Payment page. - Duplicate tab, On the duplicate, add more products to your cart. - Go back to the original tab (Payment page) > Check out with Stripe. - Stripe acquirer page does not reflect the updated cart amount. - Complete payment > Website will say order is confirmed. - Go to this SO in backend Bug: SO is not confirmed and Stripe status says there is a mismatch because it did not take updated amount
Original PR description
- on Ecommerce website Add an item to your cart. - Billing/Shipping info > Stop on Payment page. - Duplicate tab, On the duplicate, add more products to your cart. - Go back to the original tab (Payment page) > Check out with Stripe. - Stripe acquirer page does not reflect the updated cart amount. - Complete payment > Website will say order is confirmed. - Go to this SO in backend Bug: SO is not confirmed and Stripe status says there is a mismatch because it did not take updated amount. Fix: double check the ammount before processing payment opw-2978244 Forward-Port-Of: odoo/odoo#104989 Forward-Port-Of: odoo/odoo#101601
o_mail_notification should only be hidden when seen from the chatter. At the moment, the notification is hidden everywhere in odoo and after this PR the notification are only hidden in the chatter opw-2720840 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104811
Original PR description
o_mail_notification should only be hidden when seen from the chatter. At the moment, the notification is hidden everywhere in odoo and after this PR the notification are only hidden in the chatter opw-2720840 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104811
The tax report handler was not being used since it was not declared in the tax report's XML. Forward-Port-Of: odoo/enterprise#33637
Original PR description
The tax report handler was not being used since it was not declared in the tax report's XML. Forward-Port-Of: odoo/enterprise#33637
Forward-Port-Of: odoo/enterprise#33621
Original PR description
Forward-Port-Of: odoo/enterprise#33621
Forward-Port-Of: odoo/enterprise#33620
Original PR description
Forward-Port-Of: odoo/enterprise#33620
This rev converts the legacy kanbanEditor to WOWL. As for the [formEditor](https://github.com/odoo/enterprise/commit/370ba732e84b8d121e3283a16dbf233d0c7ac4c8), the kanbanEditor relies on computing the xpath of each node of interest of the arch to identify it and be able to edit the view. Task-3047989 Forward-Port-Of: odoo/enterprise#33181
Original PR description
This rev converts the legacy kanbanEditor to WOWL. As for the [formEditor](https://github.com/odoo/enterprise/commit/370ba732e84b8d121e3283a16dbf233d0c7ac4c8), the kanbanEditor relies on computing the xpath of each node of interest of the arch to identify it and be able to edit the view. Task-3047989 Forward-Port-Of: odoo/enterprise#33181
Step: - install documents_project. - remove all document access for user. - go to project. - try to create project. Issue: - can not able to create project access error. Casue: - when user does not have any document access then user will not able to create document folder and here it'll try to create document folder for new project. Fix: - create document folder for new project with superuser(sudo). task-3010437 Forward-Port-Of: odoo/enterprise#33453
Original PR description
Step: - install documents_project. - remove all document access for user. - go to project. - try to create project. Issue: - can not able to create project access error. Casue: - when user does not have any document access then user will not able to create document folder and here it'll try to create document folder for new project. Fix: - create document folder for new project with superuser(sudo). task-3010437 Forward-Port-Of: odoo/enterprise#33453
The dark mode scss was loaded in normal mode. Forward-Port-Of: odoo/enterprise#33598
Original PR description
The dark mode scss was loaded in normal mode. Forward-Port-Of: odoo/enterprise#33598
The tour would throw some warnings because we tried to access the backend website view without waiting for any loading to occur. Forward-Port-Of: odoo/enterprise#33601
Original PR description
The tour would throw some warnings because we tried to access the backend website view without waiting for any loading to occur. Forward-Port-Of: odoo/enterprise#33601
When scanning a package, if there are several SML with the same product, only one of these SML will be updated. To reproduce the issue: 1. In Settings, enable "Packages" 2. Create a storable product P 3. Update its quantity: 10 x P in a package PK 4. Create, confirm and assign two planned delivery orders D01, D02 - With 3 x P - With 7 x P 5. Create and confirm a batch transfer BT with D01 and D02 6. Barcode > Batch Transfers > BT, scan PK Error: the quantity of one line is
Original PR description
When scanning a package, if there are several SML with the same product, only one of these SML will be updated. To reproduce the issue: 1. In Settings, enable "Packages" 2. Create a storable product…
When scanning a package, if there are several SML with the same product,
only one of these SML will be updated.
To reproduce the issue:
1. In Settings, enable "Packages"
2. Create a storable product P
3. Update its quantity: 10 x P in a package PK
4. Create, confirm and assign two planned delivery orders D01, D02
- With 3 x P
- With 7 x P
5. Create and confirm a batch transfer BT with D01 and D02
6. Barcode > Batch Transfers > BT, scan PK
Error: the quantity of one line is equal to 10 and the quantity of the
other one didn't change
In the Barcode app, when processing a package, we iterate on each quant,
search for a related line and update it. In the above case, the package
only has one quant (10 x P). It finds one of the lines and then simply
updates it. When we find a line, we should fulfill its need (nothing
more) and retry the search & update step with the remaining quantity.
OPW-2976150
Forward-Port-Of: odoo/enterprise#33593
Forward-Port-Of: odoo/enterprise#32682Bring back the changes introduced by the commit 6bf29f5a25d60650e8b1c4e48ac2138a8d9edc4b that got lost during reportalypse. This will allow the tax report to display taxes with a 0 percentage when it is not set to group by anything. Task id #3015714 Forward-Port-Of: odoo/enterprise#33229
Original PR description
Bring back the changes introduced by the commit 6bf29f5a25d60650e8b1c4e48ac2138a8d9edc4b that got lost during reportalypse. This will allow the tax report to display taxes with a 0 percentage when it is not set to group by anything. Task id #3015714 Forward-Port-Of: odoo/enterprise#33229
Currently, when opening a variant (aka not a root report), the options are not set properly. That is because _init_custom_options() will try to call _custom_options_initializer() from the custom handler. But if the variant does not have a custom handler, or if the method is not defined on the variant's handler, we should try to call _custom_options_initializer() on the root report's custom handler, which was not the case. This PR fixes the issue. Forward-Port-Of: odoo/enterprise#32984
Original PR description
Currently, when opening a variant (aka not a root report), the options are not set properly. That is because _init_custom_options() will try to call _custom_options_initializer() from the custom handler. But if the variant does not have a custom handler, or if the method is not defined on the variant's handler, we should try to call _custom_options_initializer() on the root report's custom handler, which was not the case. This PR fixes the issue. Forward-Port-Of: odoo/enterprise#32984
When validating a batch payment containing payments with 'SEPA Direct Debit (acquirer)' method, no xml file generated, unlike payments with 'SEPA Direct Debit' method We align the behavior for SDD (acquirer) with SDD. opw-2985984 Forward-Port-Of: odoo/enterprise#33446 Forward-Port-Of: odoo/enterprise#32020
Original PR description
When validating a batch payment containing payments with 'SEPA Direct Debit (acquirer)' method, no xml file generated, unlike payments with 'SEPA Direct Debit' method We align the behavior for SDD (acquirer) with SDD. opw-2985984 Forward-Port-Of: odoo/enterprise#33446 Forward-Port-Of: odoo/enterprise#32020
We could do the Group By directly with sql instead of doing the computations by hand afterwards. As we're already doing a sql query, we can include it here. Forward-Port-Of: odoo/enterprise#33118
Original PR description
We could do the Group By directly with sql instead of doing the computations by hand afterwards. As we're already doing a sql query, we can include it here. Forward-Port-Of: odoo/enterprise#33118
Some code was present in the translations and was mistakenly translated (supposedly in transifex) leading to runtime errors. For example `or` was translated to `of` in Dutch. OPW-3039466 Forward-Port-Of: odoo/enterprise#33536
Original PR description
Some code was present in the translations and was mistakenly translated (supposedly in transifex) leading to runtime errors. For example `or` was translated to `of` in Dutch. OPW-3039466 Forward-Port-Of: odoo/enterprise#33536
Make recurrence in sale order view readonly for confirmed SO. Forward-Port-Of: odoo/enterprise#33230
Original PR description
Make recurrence in sale order view readonly for confirmed SO. Forward-Port-Of: odoo/enterprise#33230
*: helpdesk_timesheet, timesheet_grid Prior to this commit and since odoo/odoo#94144, a default project_id is provided event for non timesheets. This commit fixes this issue by setting a context key in the `account.analytic.line` actions that are related to timesheets and by setting the default project_id only when this key is set to `True`. Related PR: - Community: odoo/odoo#104820 Forward-Port-Of: odoo/enterprise#33550
Original PR description
*: helpdesk_timesheet, timesheet_grid Prior to this commit and since odoo/odoo#94144, a default project_id is provided event for non timesheets. This commit fixes this issue by setting a context key in the `account.analytic.line` actions that are related to timesheets and by setting the default project_id only when this key is set to `True`. Related PR: - Community: odoo/odoo#104820 Forward-Port-Of: odoo/enterprise#33550
Before this commit, the following commit 4f98d3bb9e8 reviews the form view to keep the previous behavior before the OWL conversion. However, this commit lets `template_creation` label visible if the current user is not a Planning Manager, so the label will be visible and not the field. This commit hides the label is the current user is not a Planning Manager. Forward-Port-Of: odoo/enterprise#33539
Original PR description
Before this commit, the following commit 4f98d3bb9e8 reviews the form view to keep the previous behavior before the OWL conversion. However, this commit lets `template_creation` label visible if the current user is not a Planning Manager, so the label will be visible and not the field. This commit hides the label is the current user is not a Planning Manager. Forward-Port-Of: odoo/enterprise#33539
This PR fixes various bugs in Version 16.0 task-3002298 Forward-Port-Of: odoo/enterprise#32297
Original PR description
This PR fixes various bugs in Version 16.0 task-3002298 Forward-Port-Of: odoo/enterprise#32297