Friday, August 16, 2024
20 changes · saas-17.2
Resolved issues and error corrections
A duplicated settings view was removed from the website product barcode lookup module because it was not actually used by the application. This reduces unnecessary maintenance and helps avoid confusion without changing the user experience.
Original PR description
This view is not defined in the manifest and is a duplication error of product_barcodelookup/views/res_config_settings_views.xml
This fix ensures Odoo saves valid default values for gevent worker memory settings when configuration files are generated. It prevents later startup or configuration parsing errors caused by invalid empty values, improving reliability for deployments using saved configs.
Original PR description
Since [1], the memory limit for the gevent workers can be configured with the `limit_memory_*_gevent` options. However, defaults are missing. As a result, when the `--save` option is used, the config file contains `None` values for those options. Parsing this file later on will result in an error since `None` cannot be parsed as an integer value. This PR fixes this issue by providing `False` as a default value. This value was chosen over 0 because it clearly indicates the intent to ignore this option and aligns with other option defaults. [1]: https://github.com/odoo/odoo/pull/172604
This fixes a rare timing issue where Chrome could still send a screen recording frame after recording had been stopped. The change prevents unnecessary test crashes and helps keep automated validation results more reliable.
Original PR description
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered…
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered before the command to stop reaches the browser, that frame capture may complete and be dispatched.
Locally this seems to occur in about 3.5% of calls to `test_screencasts` (7 out of 200 runs). In those cases, the event sequence looks like this:
T + 0.0000s _save_screencast()
sends `Page.stopScreencast`
T + 0.0002s stop
send `Page.stopScreencast`, unsets `screencasts_dir`
T + 0.0100s _handle_screencast_frame
accesses screencasts_frames_dir
`screencasts_frames_dir` then proceed to access `screencasts_dir`, not handle it being `None`, and break.
To fix, just make `screencasts_frame_dir` return `None` if `screencasts_dir` is `None`. This makes `_handle_screencast_frame` properly no-op on the incoming frame. And remove the redundant check on `screencasts_dir` after having ack'd the frame.
Note that this issue has *not* been reported upstream for consideration, as it would require creating a bespoke test case and I can't be arsed. A search on both the tracker and the internet at large doesn't reveal anything relevant.
Example stagings failed due to this:
- https://runbot.odoo.com/runbot/build/66915127
- https://runbot.odoo.com/runbot/build/66915510
And because it's a "traceback found in the logs" it doesn't seem like the runbot is able to see / track it.This fixes a missing setting in the project customer portal so billable project information is handled correctly. It restores expected behavior that had been accidentally omitted in an earlier change, helping sales and project workflows remain consistent for portal users.
Original PR description
It was missed in 481bfa74a89595df7434a9523e0afc1813b8a774 but added back in master
Miscellaneous changes
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
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condit
Original PR description
- 17.0 <hr> - Currently, the tour is written according to the demo data. The selector .o_form_sheet div[name] input will match if the work template is 'Device Installation and Maintenance' . This template is available in the demo. If the demo loads, the default 'Device Installation and Maintenance' will be set via the post hook. When the demo does not load, we will have the default template instead. That's why we used the .o_form_sheet p.oe-command-temporary-hint class in the OR condition. - Remove import `loaded_demo_data` from industry_fsm tests because it was not in use from this [commit](https://github.com/odoo/enterprise/commit/90ca61c62ecb0e5ddcf4d1e1ec9e0a2bf27c27f1). task-4086026 Forward-Port-Of: odoo/enterprise#67846
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
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
[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
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
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
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:/
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 ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably
Original PR description
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably add a default month granularity to date(time) fields. This isn't the case inside `_read_group`, which causes a crash Solution ======== Extract the compatibility layer related to the groupby from `read_group` and use that for both methods opw-4051657 Forward-Port-Of: odoo/odoo#176672 Forward-Port-Of: odoo/odoo#174396
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#176524 Forward-Port-Of: odoo/odoo#176012
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#176524 Forward-Port-Of: odoo/odoo#176012
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
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
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
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
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#176515