Friday, August 2, 2024
3 changes · saas-17.2
Enhancements to existing features
This update adds separate memory limit settings for gevent workers, which handle long-running real-time connections and can need more database resources than regular workers. It helps administrators tune server capacity more accurately, reducing the risk of instability when those workers use extra memory.
Original PR description
The Gevent worker has specific memory requirements. These workers require more cursors than regular HTTP workers, which can be managed using the `--db_maxconn_gevent` flag. However, increasing the number of cursors also increases memory usage. Therefore, it is beneficial to introduce options to customize memory limits specifically for gevent workers. This PR introduces `--limit-memory-soft-gevent` and `--limit-memory- hard-gevent` options to customize memory limits for gevent workers. task-4045580
Resolved issues and error corrections
After an update, older browser tabs can keep using an outdated live connection in the background. This change detects those outdated tabs, stops them from reconnecting, and prompts users to reload so they move to the current version faster.
Original PR description
The WebSocket worker is tied to a specific version. When this version changes, the worker's URL updates, creating a new worker. The old worker remains active as long as clients are connected to it. The updates may take time to propagate, leading to both the old and new workers being active simultaneously. This PR introduces a mechanism to ensure that client code updates are applied quicker. When the worker opens a WebSocket connection (typically after the server comes back online following an update), it provides the server with its version. If the version is outdated, the server closes the connection. Consequently, the worker will no longer open new WebSocket connections. Clients connected to an outdated worker will receive a notification prompting them to reload the tab. Additionally, outdated tabs will not be considered for the main tab election process.
Fixed an issue where users could not open the manufacturing order overview when the same product was used as both a component and a by-product. This prevents an error screen and lets valid manufacturing orders be reviewed normally.
Original PR description
Steps to reproduce: - Manufacturing > Products > Bills of Material > New - Add any item as component then the same item as by-product - Confirm - Operations > Manufacturing Order > New - Pick the…
Steps to reproduce: - Manufacturing > Products > Bills of Material > New - Add any item as component then the same item as by-product - Confirm - Operations > Manufacturing Order > New - Pick the product associated to your newly created BoM - Confirm > Overview What happens and why: Odoo raises an RPC error due to an inifinite recursion between _get_components_data and _get_replenishment_lines. Both calls are made before the manufacturing order line is flagged as processed so the functions are mutually dependant on the other finishing first. The looping call is conitionally called when document_in and document_out are the same, which seems to be why the stock moves 'move_in' (component) and 'move_out' (by-product) need to be configured this way on the BoM. Why is this an error: This prevents the user from accessing the overview of a valid MO. What this fix does: Moves the flag to before the looping call can be made, so the recursive call does not propagate infiniely. opw-4013371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr