Daily updates from Odoo
Friday, August 2, 2024
15 changes
3 changes
Resolved issues and error corrections
Mass mailing smart buttons now show activity only for the specific mailing being viewed, rather than totals from all mailings in the database. This gives users accurate counts and prevents confusion when assessing an individual campaign's performance.
Original PR description
The smart buttons on mass mailings were tracking all mailing traces on the database instead of only mailing traces belonging to the mass mailing in question. Adding a filter on each of these cases to only track traces belonging to the mass mailing in question fixes this issue. opw-3950732 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
3 changes
Resolved issues and error corrections
Operation type names in the Brazilian AvaTax localization can now appear in the user's language. This fixes a missing translation setting, improving clarity for Portuguese and multilingual users without changing tax behavior.
Original PR description
translate=True was forgotten when the l10n_br.operation.type model was added. Since it requires a database change it can only be done in master. Thanks to TIC for notifying us. task-3803424
This fixes an issue in Point of Sale where connected weighing scales could reference the wrong IoT device address. It helps ensure scale integrations connect reliably during checkout, reducing disruption for stores using IoT hardware.
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.
9 changes
Resolved issues and error corrections
Fixed a bug where AvaTax fixed tax amounts were incorrectly being interpreted as percentage-based taxes. When computing taxes for invoices using AvaTax, fixed fees (like a $0.29 delivery fee) were being displayed as percentages (29.0000%), causing incorrect tax calculations. This fix ensures that fixed taxes from AvaTax are properly recognized and applied as fixed amounts rather than percentages.
Original PR description
To reproduce: Activate Avatax (in Sandbox mode) Create an invoice to a partner from Colorado Put the 0F4000000 code on the Avatax Category of a product Create a line with this product Click on "Compute Taxes" => A tax named "Retail Delivery Fee [08] (29.0000 %)" is created The issue is that if you look on Avatax, it's supposed a fixed 0.29 tax. opw-4036105 Forward-Port-Of: odoo/enterprise#66973
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.
The barcode command labels in the Manufacturing work order system have been updated from "CONTINUE/PAUSE" to "CONTINUE/START" for better clarity. This change improves the user experience by using more intuitive terminology for barcode-based operations in the manufacturing workflow.
Original PR description
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616
This update fixes an issue where delivery tests were failing when run without demo data. The tests were referencing a demo partner ('Deco Addict') that doesn't exist in no-demo environments. The fix ensures tests create the necessary partner data when needed, making the test suite more reliable across different configurations.
Original PR description
The Issue: Before this commit, the test always assumed the existence of the 'Deco Addict' partner. However, in the 'no demo' test, we run tests without demo data, so this partner does not exist. The Fix: Create the demo Partner runbot-58765
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 fixes multiple compliance issues in Ecuador's ATS (Anexo Transaccional Simplificado) tax report to align with SRI (tax authority) requirements. The changes remove unsupported document types that cause validation errors, correct how sales transactions are filtered and reported by commercial partner and establishment location, and update related test cases to ensure accurate tax reporting.
Original PR description
### Fixes in ATS report:
- Remove foreign documents '15' and '110'. SRI DIMM returns a validation error
- In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number).
- In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS
- In sales, Get all the establishments registered at the SRI (tag "ventasEstablecimiento"). As it says the Technical Sheet of ATS
- Fix Unit testsThis 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: