Friday, August 16, 2024
17 changes · saas-17.1
Miscellaneous changes
Issue ----- When setting a "Counted Quantity" of 0 in the inventory adjustment, the difference would incorrectly stay as 0. Steps ----- 1. Inventory > Operations > Physical Inventory. 2. Set the "Counted Quantity" of a line where it is not set to 0. -> The difference stays at 0. Cause ----- The widget was previously relying on an onchange being triggered even if the actual value wasn't changed in input fields. This beahviour was modified by https://github.com/odoo/odoo/commit/dc
Original PR description
Issue ----- When setting a "Counted Quantity" of 0 in the inventory adjustment, the difference would incorrectly stay as 0. Steps ----- 1. Inventory > Operations > Physical Inventory. 2. Set the "Counted Quantity" of a line where it is not set to 0. -> The difference stays at 0. Cause ----- The widget was previously relying on an onchange being triggered even if the actual value wasn't changed in input fields. This beahviour was modified by https://github.com/odoo/odoo/commit/dcba2a87b7ab15b357d57c410868f19e829a8db0. https://github.com/odoo/odoo/blob/69de944b95a9790548b239f3bf05ba48eda2efef/addons/web/static/src/views/fields/input_field_hook.js#L74 Since then, changing the value from 0.00 to 0 won't trigger the onchange and the difference won't be computed. Change ----- Update the record on blur, in the same way it is already done on keydown. opw-4064858 opw-4063994 Forward-Port-Of: odoo/odoo#175680
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any lead 4. Click on Actions > Add properties 5. Input anything as value, then save 6. Make a xmlrpc call to retrieve leads (see below) 7. Traceback `models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])` Cause of the issue: --- Feature introduction: https://github.com/od
Original PR description
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any…
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any lead 4. Click on Actions > Add properties 5. Input anything as value, then save 6. Make a xmlrpc call to retrieve leads (see below) 7. Traceback `models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])` Cause of the issue: --- Feature introduction: https://github.com/odoo/odoo/commit/87307a9010c6c872fe6c746d5ece378ad90d038f Change from `None` to `False`: https://github.com/odoo/odoo/commit/608bffff59c9444f59a282dbdc43c207704223cc Issue caused by: https://github.com/odoo/odoo/commit/da48700b59da49cdc810eac31a8617fcaa0dc2a8 (Due to the modification of `convert_to_read_multi`) When adding `PropertiesDefinition` to an existing record, it doesn't go through `_add_default_values` again, thus making `None` not being replaced by `False`. https://github.com/odoo/odoo/blob/cd9c69bd7d9b21e6220a49f88f22160de33c5e06/odoo/fields.py#L3616 opw-3940841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172689
Therefore there's nothing especially wrong in styling it like a button e.g. in the statusbar. Forward-Port-Of: odoo/odoo#176616
Original PR description
Therefore there's nothing especially wrong in styling it like a button e.g. in the statusbar. Forward-Port-Of: odoo/odoo#176616
Steps to reproduce: - Time off > Calendar view > Double click on a day - Sick leave > Attach document > Save - View the leave from calendar The attachment preview window overlaps the leave modal information, making it unreadable. The preview is only displayed above large media breakpoints (> 1550px) so make sure to fullscreen. In 16.0 we used a custom element to render the preview which is no longer available https://github.com/odoo/odoo/commit/824024f8aaa4a5419646d4eec7f529277869ceac#
Original PR description
Steps to reproduce: - Time off > Calendar view > Double click on a day - Sick leave > Attach document > Save - View the leave from calendar The attachment preview window overlaps the leave modal information, making it unreadable. The preview is only displayed above large media breakpoints (> 1550px) so make sure to fullscreen. In 16.0 we used a custom element to render the preview which is no longer available https://github.com/odoo/odoo/commit/824024f8aaa4a5419646d4eec7f529277869ceac#diff-a5f278935504f8e1b287b52fbb88f6e58dedc727ec2c7f1a6a04a67202f18fdaR63. opw-4088218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176598
IoT image was missing `xinput` dependency. Required by: [https://github.com/odoo/odoo/pull/174009](https://github.com/odoo/odoo/pull/174009) Forward-Port-Of: odoo/odoo#176751
Original PR description
IoT image was missing `xinput` dependency. Required by: [https://github.com/odoo/odoo/pull/174009](https://github.com/odoo/odoo/pull/174009) Forward-Port-Of: odoo/odoo#176751
Backport of: a9be2e45d8db5011cfcbef8f5d81ce4127d5d151 Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed e
Original PR description
Backport of: a9be2e45d8db5011cfcbef8f5d81ce4127d5d151 Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed entirely. opw-3911429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176742 Forward-Port-Of: odoo/odoo#173645
Steps to reproduce the bug: - Create a subcontracted product “P1”: - the valuation: AVCO automated - BoM: - component: C1 ($15) - Go back to the product form for “P1.” - Click on "Compute from BoM" -> Result: P1 = $15. - Create a Purchase order: - 1 unit of P1 - Confirm the PO and receive P1 - Return the received quantity: - Location: “Partner/lcoation” **Problem:** A traceback is triggered: ``` File "/home/odoo/src/odoo/addons/mrp_subcontracting_purchase
Original PR description
Steps to reproduce the bug: - Create a subcontracted product “P1”: - the valuation: AVCO automated - BoM: - component: C1 ($15) - Go back to the product form for “P1.” - Click on "Compute from BoM"…
Steps to reproduce the bug:
- Create a subcontracted product “P1”:
- the valuation: AVCO automated
- BoM:
- component: C1 ($15)
- Go back to the product form for “P1.”
- Click on "Compute from BoM" -> Result: P1 = $15.
- Create a Purchase order:
- 1 unit of P1
- Confirm the PO and receive P1
- Return the received quantity:
- Location: “Partner/lcoation”
**Problem:**
A traceback is triggered:
```
File "/home/odoo/src/odoo/addons/mrp_subcontracting_purchase/models/stock_valuation_layer.py", line 21, in _get_layer_price_unit
return super()._get_layer_price_unit() + components_price
File "/home/odoo/src/odoo/addons/purchase_stock/models/stock_valuation_layer.py", line 12, in _get_layer_price_unit
return self.value / self.quantity
ZeroDivisionError: float division by zero
```
When validating the return, the `_account_entry_move` function is called to verify if the returned value of the product is different from the purchased one. In this case, we need to clear the `stock_in` account with the difference. To do this, we retrieve the layer associated with the origin move of the return. However, since this move is an internal one (from the subcontracting location to WH/stock), the `_should_be_valued` function returns `False`, and no layer is created for this move:
https://github.com/odoo/odoo/blob/7afd9294338dd18c3351afd2017648931fdb9ee3/addons/stock_account/models/stock_location.py#L25-L30
Because we do not check if a layer exists for this move and directly call the `_get_layer_price_unit` function, a traceback is triggered as we have division by zero
**Solution:**
In case there is no layer associated with the original move, we can consider the difference as 0.
For example, in our case, the layer of the returned move has a value of 30 (15 for P1 and 15 for C1). Therefore, even if we return P1 to the subcontractor, we will not return the value of C1 because it has already been delivered and used.
opw-4053362
Forward-Port-Of: odoo/odoo#176515Steps to reproduce: - Enable storage locations - Inventory > Internal Transfers - Gear Icon > Import records - Try to import a file containing picking type Picking type cannot be imported because it is a readonly field, this is even more problematic since picking_type_id is a required field, thus preventing the import of any other data. Previously, the field picking_type_id used to have a state attribute to make it editable when in draft, but this is no longer the case in 17.0. https:/
Original PR description
Steps to reproduce: - Enable storage locations - Inventory > Internal Transfers - Gear Icon > Import records - Try to import a file containing picking type Picking type cannot be imported because it is a readonly field, this is even more problematic since picking_type_id is a required field, thus preventing the import of any other data. Previously, the field picking_type_id used to have a state attribute to make it editable when in draft, but this is no longer the case in 17.0. https://github.com/odoo/odoo/pull/104741 opw-4074746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175845
Steps to reproduce: - Create 2 products and publish 1 - Website > Edit > Add a "Products" block - Configure it to filter for recently sold products - Configuration > Payment Providers > Enable Demo - Configuration > Shipping methods > New - Set delivery product to your unpublished product - Publish the shipping method - From Shop buy your published product - Cart > Checkout > Use your shipping method - Validate then return to your products block The delivery products appears in
Original PR description
Steps to reproduce: - Create 2 products and publish 1 - Website > Edit > Add a "Products" block - Configure it to filter for recently sold products - Configuration > Payment Providers > Enable Demo - Configuration > Shipping methods > New - Set delivery product to your unpublished product - Publish the shipping method - From Shop buy your published product - Cart > Checkout > Use your shipping method - Validate then return to your products block The delivery products appears in recently sold, even as a portal user despite never being published and not being directly available to buy. Having unpublished products on the portal should not be possible when logged in as a portal user, much less a delivery product which is insubstantial to the user. opw-4075261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175817
There's a single change in this minor version of owl: we no longer call console.warn when a willStart/willUpdateProps callback takes more than 3s (in dev/test mode only anyway). Instead, we use console.log. The reason is that some willStart/willUpdateProps may sometimes take more than 3s (because they lazyload bundles for instance). When this happens, if a warning is logged, the runbot will be yellow and the build will fail. In master, it happenned a lot recently, in tours involving the We
Original PR description
There's a single change in this minor version of owl: we no longer call console.warn when a willStart/willUpdateProps callback takes more than 3s (in dev/test mode only anyway). Instead, we use console.log. The reason is that some willStart/willUpdateProps may sometimes take more than 3s (because they lazyload bundles for instance). When this happens, if a warning is logged, the runbot will be yellow and the build will fail. In master, it happenned a lot recently, in tours involving the WebsiteEditorComponent, which loads the wysiwyg bundle, and since recently, jquery [1]. For that reason, we decided to log instead of warn, at least temporarily, s.t. the skipped tours can be unskipped. [1] odoo/odoo#174213 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#176783
[FIX] l10n_bd: fix loading account template The issue is that I put the account tags templates in the manifest to load into demo section which cause issues when user try to load the package without demo data as It will not going to load Solution: moving the account tags template/states to the data section task-id#3974212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176845
Original PR description
[FIX] l10n_bd: fix loading account template The issue is that I put the account tags templates in the manifest to load into demo section which cause issues when user try to load the package without demo data as It will not going to load Solution: moving the account tags template/states to the data section task-id#3974212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176845
Automatically close the print dialog after the user confirms the print job. This enhancement improves user experience by eliminating the need for users to manually close the dialog, streamlining the printing process. Initially, we considered keeping the modal open until all print operations completed successfully. If any printer encountered an error, the modal would remain open. However, this approach doesn't assist users in resolving the issue, as they would still need to close the modal to
Original PR description
Automatically close the print dialog after the user confirms the print job. This enhancement improves user experience by eliminating the need for users to manually close the dialog, streamlining the printing process. Initially, we considered keeping the modal open until all print operations completed successfully. If any printer encountered an error, the modal would remain open. However, this approach doesn't assist users in resolving the issue, as they would still need to close the modal to correct the problem. Therefore, it is more user-friendly to automatically close the modal after user confirmation. https://github.com/user-attachments/assets/659d971e-25c8-487f-8c02-cf0f5461a920 Forward-Port-Of: odoo/enterprise#68256 Forward-Port-Of: odoo/enterprise#68195
Partial revert of https://github.com/odoo/enterprise/commit/318ae33da2e36036e1a74028a36d02ad4fa5964e (we keep the test and revert the fix). The reverted commit intended to soluve issues with hide_if_zero, and had it consider the string values as 0. However, in 17.2+, this caused issues with the blank_if_zero columns, which then never showed such string values. We revert the original fix and take a new approach in this commit ; we do that in 17.0 instead of 17.2 just for homogeneity of the
Original PR description
Partial revert of https://github.com/odoo/enterprise/commit/318ae33da2e36036e1a74028a36d02ad4fa5964e (we keep the test and revert the fix). The reverted commit intended to soluve issues with hide_if_zero, and had it consider the string values as 0. However, in 17.2+, this caused issues with the blank_if_zero columns, which then never showed such string values. We revert the original fix and take a new approach in this commit ; we do that in 17.0 instead of 17.2 just for homogeneity of the code base, and ease of maintenance on longer term. The new strategy is bacisally to consider non-number values as 0 only when handling the hide_if_zero option, without touching to the computation of the is_zero key of column dicts. Also, this commit explicitly adds the 'percentage' figure_type to the ones checked by the 'is_zero' key in column dicts: percentages are numeric values; ignoring them there was wrong. Forward-Port-Of: odoo/enterprise#68450
## Issue: - changing the next invoice date to a future date in the subscription app incorrectly changes the subscription status to "To be invoiced" ## Steps To Reproduce: - create subscription, and confirm it - Run the scheduled action: 'Sale Subscription: generate recurring invoices and payments' - change the 'Date of Next Invoice' on the subscription. - Notice that the related quotation invoice status is `To invoice` ## Solution: - Changing next_invoice_date or last_invoice_date sh
Original PR description
## Issue: - changing the next invoice date to a future date in the subscription app incorrectly changes the subscription status to "To be invoiced" ## Steps To Reproduce: - create subscription, and confirm it - Run the scheduled action: 'Sale Subscription: generate recurring invoices and payments' - change the 'Date of Next Invoice' on the subscription. - Notice that the related quotation invoice status is `To invoice` ## Solution: - Changing next_invoice_date or last_invoice_date should not impact the quantity invoiced, as invoiced amounts should remain unchanged. - Therefore, I removed `order_id.next_invoice_date` and `order_id.last_invoice_date` from the dependencies of `_compute_qty_invoiced`. opw-3932847 Forward-Port-Of: odoo/enterprise#65203
Before this commit, the bottom right label in sign templates which included the hourglass icon was overlapping the action buttons and the search panel in the left position of the screen was occupying a big part of the screen when the width was small, hiding the sign templates and sign documents in the bottom of the page. After this commit, the bottom right label does not overlaps the action buttons anymore and when the screen is small (in width) we hide the search panel for showing the sign t
Original PR description
Before this commit, the bottom right label in sign templates which included the hourglass icon was overlapping the action buttons and the search panel in the left position of the screen was occupying a big part of the screen when the width was small, hiding the sign templates and sign documents in the bottom of the page. After this commit, the bottom right label does not overlaps the action buttons anymore and when the screen is small (in width) we hide the search panel for showing the sign templates and sign documents correctly. task-4077791 Forward-Port-Of: odoo/enterprise#67700
Forward-Port-Of: odoo/enterprise#68211
Original PR description
Forward-Port-Of: odoo/enterprise#68211
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#63822
Original PR description
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#63822