Odoo Changelog — 2024-08-16

Friday, August 16, 2024

4 changes · saas-17.2

Bug Fixes(4)

Resolved issues and error corrections

[FIX] website: avoid failing during wysiwyg adapter's destroy

Coresaas-17.2websiteMedium

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

#website#editor#error prevention

[FIX] base: missing default for gevent memory options

PR #176773

Coresaas-17.2base

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

#configuration#gevent#memory#stability

[FIX] core: race condition in screencast finalisation

PR #176893

Coresaas-17.2core

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…

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.

[FIX] sale_project: add missing allow_billable context to project portal

PR #176931

Coresaas-17.2sale_project

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

#project portal#billing#sales

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

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

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.