Friday, August 2, 2024
14 changes
3 changes
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
4 changes
Enhancements to existing features
The timesheet timer is now preserved when users move between timesheet views, reducing the risk of losing tracked work time. If a timer starts without a default project, the system keeps it temporarily and automatically saves it once a project is selected.
Original PR description
Remove unnecessary code from `timesheet_timer_hooks.js`. Add a hook `onRecordChanged` to the timesheet controllers to manage the usecase where we start a timer, but no "default" project is found. In that case, we create a "fake" record in the view (we don't save it because without project, it is not qualified as a timesheet but as an analytic line). As soon as a project is set on it however, we want to save it, and that is what the hook does. related: https://github.com/odoo/odoo/pull/154134 task-3594778
New spreadsheet dashboards created from the Documents app are now published by default, so users can find them immediately on the main Dashboards page. This reduces confusion and removes the extra step that previously kept newly created dashboards hidden.
Original PR description
Purpose ------- When users create a spreadsheet in the Documents app, then convert it to a dashboard (File > Add to dashboards), they don't understand why the spreadsheet doesn't appear in the main Dahsboards landing action. The reason is that the dashboard is not publised by default Spec ---- Set dashboard to published by default to avoid not finding your dashboard Task: 4077300
Barcode lookup now only runs for products using recognized EAN or UPC barcode formats. This helps avoid unnecessary lookups and prevents invalid barcode lengths from being accepted during product creation.
Original PR description
Previously, the barcode lookup was triggered for barcodes of any length, and the product creation form accepted barcodes of any length. With this commit ================= The barcode lookup will now be restricted to only those barcodes encoded in EAN or UPC formats. Additionally, the product creation wizard will only accept barcodes in the specified formats. [3974067](https://www.odoo.com/odoo/my-tasks/3974067?cids=2)
Resolved issues and error corrections
This update fixes time selection and display issues for locales that use 12-hour clocks with AM/PM. It helps users avoid incorrect shift or rental times when working in affected regional settings.
7 changes
New functionality added to Odoo
This update adds support for the Spanish Modelo 130 tax report, a new compliance requirement for Spanish businesses. The feature includes the ability to generate and export tax reports in the official BOE (Spanish Official Gazette) format, helping Spanish companies meet their tax reporting obligations more efficiently.
Original PR description
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946
Enhancements to existing features
This update improves the CodaBox integration for Belgian accounting by adding a dashboard button to quickly view draft SODA entries, adding a password verification step during connection setup to prevent errors, and including a link to documentation for easier user guidance. These changes make the system more user-friendly and help prevent connection mistakes.
Original PR description
1. Add a button in the dashboard to view the number of drafts SODA entries for the CodaBox Soda journal. This button opens the SODA draft entries 2. Add a new non-stored field on the validation wizard to verify that the user has correctly copied the Accounting Firm password. If not, the 'Validate connection' button will be disabled 3. Add a link to the documentation in the connection wizard task-id 4008140
Resolved issues and error corrections
A bug was fixed in the Field Service Management timesheet creation process where a return statement was missing from the save_timesheet function. This fix ensures the function properly completes its operation and returns the expected result, preventing potential errors when users save timesheets for field service tasks.
This update fixes a technical issue in the timesheet timer feature where certain initialization steps weren't completing properly, which could cause display problems. The fix also improves performance by streamlining code and running multiple data requests simultaneously instead of sequentially.
Original PR description
In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs.
This fix resolves an issue where manufacturing order quantities of 1,000 units or more were being incorrectly truncated in the Shop Floor display (e.g., 2,500 units showed as "2"). The problem was caused by unnecessary data conversions in the display code. After this fix, quantities now display correctly and completely, improving accuracy in the manufacturing workflow.
Original PR description
Steps to reproduce: - Manufacturing > Products > BoM - Create BoM with at least 1 operation - New MO with Quantity to produce >= 1000 - Shop Floor > Remove filters What happens: Work order card…
Steps to reproduce: - Manufacturing > Products > BoM - Create BoM with at least 1 operation - New MO with Quantity to produce >= 1000 - Shop Floor > Remove filters What happens: Work order card truncates number of units to produce by 3 digits, i.e. a quantity of 2500 displays as 2, 34000 as 34, etc... This is caused by the successive conversions in formatFloat, they go: Number (quantityToProduce) > String (formatFloat) > Number (ParseFloat) > String (String()) Which looks to be a dirty solution to forcefully display the float as an integer value. What this fix does: Getting rid of the superfluous conversions fixes the truncating issue. The decimal precision was set to default to integer values if the precision props is not defined to conserve the original behavior since manufacturing fractions of a product seems nonsensical, but it seems a precision was passed all along and simply failed to display because of the aforementioned issue. So now 2500 displays as 2500.00 not sure if that was intended or just ignored because of the previous display weirdness. opw-4040457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where the Belgian tax report posting wizard incorrectly checked the company's country code instead of the report's country code. This caused errors when users tried to create closing entries for foreign VAT fiscal positions (such as French tax reports on a Belgian company). The fix now properly detects the correct country code for the report being processed.
Original PR description
Currently we just check whether the company has 'BE' fiscal country code. But this can be incorrect: We may want to create a report for a foreign VAT fiscal position. This situation can lead to a traceback (see below). After this commit we use the dedicated helper function `_get_report_country_code` to determine the right country code. Reproduce: 1. Install `l10n_be_reports` and `l10n_fr_reports` 2. On the Belgian company create a fiscal position with country 'France' and a 'Foreign Tax ID' 3. On the Belgian company open the tax report and select the French tax report 4. Click on the "Closing Entry" button to create a draft closing entry move 5. Try to post the move 6. Traceback (in which `l10n_be_reports_post_wizard` appears) task-4063968 Forward-Port-Of: odoo/enterprise#67548 Forward-Port-Of: odoo/enterprise#67122
This update corrects how currency exchange rates are calculated when currencies have different conversion ratios (like Turkish lire at 100 TRY = 18.30 BGN). Previously, the system was not accounting for these ratio differences, leading to inaccurate exchange rates. The fix ensures all currency conversions are calculated correctly by properly factoring in the ratio multiplier.
Original PR description
Description of the issue/feature this PR addresses: Added parsing and multiplication of 'RATIO' field with 'REVERSERATE' for more accurate currency rate calculations. For example, Turkish lire is per 100 TRY 18.30 BGN. The current date is also adjusted to use today's date correctly within the function. Current behavior before PR: Wrong calculation of currencies with different ratio <> 1.0 Desired behavior after PR is merged: