Daily updates from Odoo
Friday, August 16, 2024
15 changes · saas-17.2
Resolved issues and error corrections
This fix prevents an error dialog from appearing when a logged-in user edits a website page and then uses the browser back button. It makes the website editor cleanup more reliable, reducing disruption for users managing website content.
Original PR description
Since [1] when routing was changed to path-based, the website service's `pageDocument` can be reset before the wysiwyg adapter is destroyed. Because of this, the `destroy` might fail - leading to further errors. Steps to reproduce: - Be logged in. - Access the visitor view of the Home page. - Click on the "Editor" link to reach the back-end view. - Click on "Edit". - Click on the back button of the browser. => An error dialog appears. [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f opw-4074988
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
[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