Thursday, November 4, 2021
17 changes · master
Enhancements to existing features
Financial report control checks now cover more formula types, not just basic sum formulas. This helps businesses get more reliable report validations across positive, negative, and grouped calculations.
Original PR description
Currently, control domains only cover cases when the "formulas" field is "(-)sum". The goal is to be able to handle the other cases as well : - sum_if_pos(neg) - sum_if_pos(neg)_groupby
Resolved issues and error corrections
The forum question page now handles visits from helpdesk tickets correctly, so the back button returns users to the related ticket instead of sending them to the app switcher or showing the wrong navigation. This reduces confusion for support teams moving between helpdesk and forum content.
Original PR description
purpose of this commit is to remove the back button of the forum page when the user opens the question from helpdesk ticket before this commit, the back button displays on the forum page when the user opens the question from the helpdesk ticket. Task-2602604 Related: odoo/enterprise#21219
Miscellaneous changes
This reverts commit 3b3a47f0d3414ae5bee159f6ec4644e64441040f. This commit is reverted because it re-adds a field (`origin`) who isn't in the model `repair.order` which causes traceback when the user wants to send a quotation from a repar order. Forward-Port-Of: odoo/odoo#78246
Original PR description
This reverts commit 3b3a47f0d3414ae5bee159f6ec4644e64441040f. This commit is reverted because it re-adds a field (`origin`) who isn't in the model `repair.order` which causes traceback when the user wants to send a quotation from a repar order. Forward-Port-Of: odoo/odoo#78246
The Project app now shows the project update button only once instead of duplicating it. This reduces visual clutter and prevents confusion for users managing project updates.
Original PR description
Prior to this fix:
The project update stat button is duplicated.
After this fix:
The project update stat button is no more duplicated.
task-2684233
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a display issue in the grid view where updated timesheet totals briefly appeared and then reverted to the previous value after selecting a cell. It helps users trust that the totals they see after entering time in days remain accurate and up to date.
Original PR description
Steps to reproduce: https://drive.google.com/file/d/1STB44wxVxkBCn-V4uIVMnI3TY7xJmj4R/view go to timesheets > settings > change the encoding unit to 'days' go to the 'all timesheets' menu and encode a few timesheets Observed behavior: when clicking on a cell, the new total is quickly displayed and then is reset to the previous value clicking on another cell makes the new total appear again Expected behavior: the new total should remain displayed after clicking on a cell This PR aims at having comprehensive tests to mimic the erratic behavior of the web_grid observed above. The tests are expected to fail but any fix brought to web_grid will hopefully fix them task-2522612
and point links directly to https Description of the issue/feature this PR addresses: Status images in README.md are loaded over http instead of https, when viewed locally / on a gitlab fork. Github seems to inject its own "safe" proxy. Current behavior before PR: status images are loaded over http Desired behavior after PR is merged: status images are loaded over https Info @wt-io-it -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
and point links directly to https Description of the issue/feature this PR addresses: Status images in README.md are loaded over http instead of https, when viewed locally / on a gitlab fork. Github seems to inject its own "safe" proxy. Current behavior before PR: status images are loaded over http Desired behavior after PR is merged: status images are loaded over https Info @wt-io-it -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79286 Forward-Port-Of: odoo/odoo#78666
In 1e93c161ca454313436b65427542db961f6ddcdd we trigger RR when confirming a MO. Same thing should be done if we changed the product qty for a confirmed MO. Task-2653116 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#77508
Original PR description
In 1e93c161ca454313436b65427542db961f6ddcdd we trigger RR when confirming a MO. Same thing should be done if we changed the product qty for a confirmed MO. Task-2653116 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#77508
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#78702
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#78702
The component status of a MO is not correctly computed To reproduce the issue: (Use demo data) 1. Create and confirm a MO for 1 x [FURN_9666] Table 2. Unlock and edit the target of To Consume Qty: - For [FURN_8522] Table Top: 0.1 - For [FURN_2333] Table Leg: 0.1 Error: The Component Status of the MO becomes "Available" while Table Top and Table Leg are not available. Due to the signature of `float_compare`: https://github.com/odoo/odoo/blob/56f8c1c0487bf95325ca859e2f266d1
Original PR description
The component status of a MO is not correctly computed
To reproduce the issue:
(Use demo data)
1. Create and confirm a MO for 1 x [FURN_9666] Table
2. Unlock and edit the target of To Consume Qty:
- For [FURN_8522] Table Top: 0.1
- For [FURN_2333] Table Leg: 0.1
Error: The Component Status of the MO becomes "Available" while Table
Top and Table Leg are not available.
Due to the signature of `float_compare`:
https://github.com/odoo/odoo/blob/56f8c1c0487bf95325ca859e2f266d1beed28ad4/odoo/tools/float_utils.py#L127
`move.product_id.uom_id.rounding` is implicitly given to
`precision_digits`, which is incorrect.
OPW-2669931
Forward-Port-Of: odoo/odoo#79302we recently fixed this issue via this commit: https://github.com/odoo/odoo/pull/78377/commits/f3bb0dcc013960d6a43b9182b7daa5d33cab5aaa But we forgot to add a “break” in the loop in order to go to the next available interval when the current interval duration has been used the test has been modified to better cover the use case -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79317
Original PR description
we recently fixed this issue via this commit: https://github.com/odoo/odoo/pull/78377/commits/f3bb0dcc013960d6a43b9182b7daa5d33cab5aaa But we forgot to add a “break” in the loop in order to go to the next available interval when the current interval duration has been used the test has been modified to better cover the use case -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79317
In a multi-warehouses environment, editing the quantities of the cart products can lead to incorrect behaviors. To reproduce the issue: (Let WH01 be the default company's warehouse) 1. Create a second warehouse WH02 2. In Settings > Website > Products: - Inventory > Warehouse: WH01 3. Create a product P: - Type: Storable - Availability: Show inventory on website and prevent sales if not enough stock - Available on eShop 4. Update P's quantity: - Location: WH01/
Original PR description
In a multi-warehouses environment, editing the quantities of the cart products can lead to incorrect behaviors. To reproduce the issue: (Let WH01 be the default company's warehouse) 1. Create a…
In a multi-warehouses environment, editing the quantities of the cart
products can lead to incorrect behaviors.
To reproduce the issue:
(Let WH01 be the default company's warehouse)
1. Create a second warehouse WH02
2. In Settings > Website > Products:
- Inventory > Warehouse: WH01
3. Create a product P:
- Type: Storable
- Availability: Show inventory on website and prevent sales if not
enough stock
- Available on eShop
4. Update P's quantity:
- Location: WH01/Stock, Qty: 10
5. Create a sale order SO:
- Lines:
- 100 x P
- Warehouse: WH02
6. Confirm SO
7. Go on eShop
8. Add P to the cart
9. On cart page, increase the quantity of P
Error: The quantity becomes -90 (then the product is automatically
removed from the cart)
The quantity maximum that the user can select is defined thanks to:
https://github.com/odoo/odoo/blob/8d2fd05382705d4b3987ebac4c842d8507ede9cf/addons/website_sale_stock/views/website_sale_stock_templates.xml#L12
When computing all the quantities (in `_compute_quantities_dict`), if
there isn't any warehouse in the context, the quantities will be
calculated on the basis of all warehouses:
https://github.com/odoo/odoo/blob/48698838dd47442145395d3d4396b64b6901dba1/addons/stock/models/product.py#L238-L248
As a result, in the above case, `virtual_available` will be equal to
`10 - 100 = -90`. However, a SO is linked to a specific warehouse, so
the computations should be based on this warehouse. That way,
`virtual_available` will be 10 and, when editing the quantities in the
cart, the maximum value will be correctly computed.
OPW-2667470
Forward-Port-Of: odoo/odoo#78823Cherry pick of commits to change the commit message Forward-Port-Of: odoo/odoo#79360
Original PR description
Cherry pick of commits to change the commit message Forward-Port-Of: odoo/odoo#79360
Steps to reproduce the bug: - Install sale_ebay - Go to inventory settings > Enable “Units of Measure” option - Create a new storable product > save - Edit > Change the Uom - Traceback is triggered Problem: When ebay is installed, there is a list on the form of a product template. This list displays all variants and some of their fields. One of these is “virtual_available” which is a computed field. When changing the UoM of the product, the _compute_quantitie method will be triggered.
Original PR description
Steps to reproduce the bug: - Install sale_ebay - Go to inventory settings > Enable “Units of Measure” option - Create a new storable product > save - Edit > Change the Uom - Traceback is triggered Problem: When ebay is installed, there is a list on the form of a product template. This list displays all variants and some of their fields. One of these is “virtual_available” which is a computed field. When changing the UoM of the product, the _compute_quantitie method will be triggered. However, since the UoM isn't defined in the tree view of the variants, this field will be false during the computations. This will lead to an error as the UoM is required for the compute method to be correctly processed: https://github.com/odoo/odoo/blob/15.0/addons/stock/models/product.py#L186 opw-2669079 Forward-Port-Of: odoo/enterprise#22090
we recently fixed this issue via this commit: https://github.com/odoo/enterprise/pull/21701/commits/b2ba910b31ea1e6bd5f09e8bcabfcb19215edd22 But we forgot to add a “break” in the loop in order to go to the next available interval when the current interval duration is used the test has been modified to better cover the use case Forward-Port-Of: odoo/enterprise#22071
Original PR description
we recently fixed this issue via this commit: https://github.com/odoo/enterprise/pull/21701/commits/b2ba910b31ea1e6bd5f09e8bcabfcb19215edd22 But we forgot to add a “break” in the loop in order to go to the next available interval when the current interval duration is used the test has been modified to better cover the use case Forward-Port-Of: odoo/enterprise#22071
Before this commit, we try to get the user_ids to check if only one user is assigned to the task in result of the `default_get` method. The problem is: `result.get('user_ids')` is a list of commands and not a list of user ids. This commit fixes this issue to get the user ids in the last Command.SET containing in the commends list. Steps to reproduce: ================== 1) Go to Field Service app, 2) Go to the gantt view, 3) Click on `Add` button. Observed behavior: ============
Original PR description
Before this commit, we try to get the user_ids to check if only one user
is assigned to the task in result of the `default_get` method. The
problem is: `result.get('user_ids')` is a list of commands and not a
list of user ids.
This commit fixes this issue to get the user ids in the last
Command.SET containing in the commends list.
Steps to reproduce:
==================
1) Go to Field Service app,
2) Go to the gantt view,
3) Click on `Add` button.
Observed behavior:
=================
Traceback since the list is not iterable.
Expected behavior:
=================
Get the default planned dates for the task based on the user assigned.
Forward-Port-Of: odoo/enterprise#22010Forward-Port-Of: odoo/enterprise#21805
Original PR description
Forward-Port-Of: odoo/enterprise#21805
Create an invoice with intrastat info and a 100% discount line Generate the intrastat report, download the XML and upload to government portal It is refused, because the price subtotal for the discounted line is 0 and it is not an accepted value The value is mandatory when declared, even for gifts (transaction code 3) and replacements (transaction code 6), so we may just use the subtotal before discount opw-2657646 Forward-Port-Of: odoo/enterprise#22013
Original PR description
Create an invoice with intrastat info and a 100% discount line Generate the intrastat report, download the XML and upload to government portal It is refused, because the price subtotal for the discounted line is 0 and it is not an accepted value The value is mandatory when declared, even for gifts (transaction code 3) and replacements (transaction code 6), so we may just use the subtotal before discount opw-2657646 Forward-Port-Of: odoo/enterprise#22013