Daily updates from Odoo
Thursday, December 4, 2025
13 changes · 18.0
Enhancements to existing features
This update ensures greater clarity and accuracy in Odoo's queries by consistently using fully qualified column names (e.g., `account_move.balance`). This prevents ambiguity when joining tables and avoids potential issues with custom modules, ultimately strengthening data reliability.
Original PR description
Use fully qualified column names when constructing a query, more specifically, include the table that the column is originating from. The rule of thumb is that we always include the table name alongside the column name. In this particular case, the query will do a `JOIN` on `account_move` and there may be ambiguousness as to whether to take the `balance` column from `account_move` or `account_move_line`. The former column used to exist in the past and was likely kept for data retention purposes. Hence, there are still databases in 17.0 where `account_move.balance` exists. Another reason to include the table name is to prevent confusion with columns coming from custom modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237181
This update clarifies the labeling of a field used when making salary adjustments within the HR payroll module. The change ensures users understand exactly where this input is accessible, leading to a more intuitive and efficient adjustment process. This improves usability and reduces potential errors.
Original PR description
This change ensures the label accurately reflects where the field is accessible and providing better clarity for users when working with salary adjustments. Task: 5375187
Resolved issues and error corrections
This update fixes a bug that prevented users from creating multiple rental orders with the same serial number. The issue stemmed from an incorrect assumption about stock movements, leading to errors. The fix ensures accurate availability calculations and allows for proper management of rental orders with multiple associated serial numbers.
Original PR description
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide…
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide the "Reserved Lot" field, select the lot created earlier, and confirm 5. Open the Delivery(Stat button), assign lots to both deliveries 6. Create a second rental order (same or different user), assign the same lot, confirm, and process delivery 7. Create a third rental order, enter the same reserved lot → traceback occurs Issue: - Traceback with error `ValueError: Expected singleton: stock.move(88, 90)`. Cause: - The compute method `_compute_available_reserved_lots` accessed `move_id.date_deadline` directly, assuming a singleton. When multiple stock moves existed for the same lot, it triggered a singleton error. - When the same lot is linked to more than one delivery, the system crashed when checking available reserved lot. Solution: - Handled multiple stock.move.line records per lot by iterating over them instead of assuming a singleton. - Replaced direct access to move_id.date_deadline with an any() check to safely evaluate deadlines. - This prevents singleton errors when the same lot is linked to multiple deliveries and ensures correct availability calculation. opw-4963263 Forward-Port-Of: odoo/enterprise#94299
This update corrects a bug in the vehicle availability calculations for the Belgian payroll and fleet module. It now accurately excludes vehicles flagged for change (plan_to_change_car or plan_to_change_bike) with a 'False' status, ensuring they are not incorrectly listed as available. This improves the accuracy of vehicle availability reporting.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#101014 Forward-Port-Of: odoo/enterprise#90812
This update fixes an issue where debit notes in the Uruguayan localization were incorrectly assigned as e-invoices. The fix ensures debit notes automatically use the correct document type (113) instead of 111, streamlining invoice processing for Uruguayan businesses. This improves data accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type =…
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**. * From the invoice's gear icon, create a **Debit Note**. **Observed behavior:** * The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**. * Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111. **Cause:** * `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification. * This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type. * The override prevents the correct selection (internal_type == *debit_note*) from being applied. **Fix:** * Add a condition in the automatic e-Invoice assignment logic. * Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**. opw-5154599
This update resolves an issue where switching between image and icon types in the HTML editor didn't correctly remove outdated class names. Previously, images could retain invalid classes like 'w-100' when switched to an icon. This fix ensures that the HTML editor consistently removes irrelevant classes, improving the editor's functionality and preventing potential display issues.
Original PR description
Before this commit, switching the media type would not properly remove the classes of the element. For example, images can have the class "w-100" while icons cannot. If an image had the class "w-100", switching to an icon would keep the class "w-100", even though this class isn't valid for icons. This commit fixes the code to properly remove all invalid classes.
This update resolves a problem where the tax upgrade script incorrectly translated strings, leading to errors. The fix ensures consistent translation across different language environments, preventing disruptions during upgrades. This improves the stability and reliability of the tax processing functionality.
Original PR description
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade,…
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade, those strings will be translated in different languages and will trigger an error[^1] when they cannot be accessed in the dict. This can also fail during a local upgrade, not necesarily during an upgrade in the platform.
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Akun'
```
[^1]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L423
[^2]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L393-L397
Forward-Port-Of: odoo/odoo#238368This update fixes an issue where zero margins and spacing settings in reports weren't being applied correctly when using wkhtmltopdf. Now, users can accurately set margins and spacing to zero, ensuring reports are generated with the desired layout. This improves report customization options.
Original PR description
When constructing the wkhtmltopdf command arguments, the system retrieves values from the `specific_paperformat_args` dictionary using get and checks whether the returned value is falsy. Because 0 is a falsy value in Python, margin and header spacing values explicitly set to 0 are mistakenly ignored. As a result, the system incorrectly falls back to the default paperformat values instead of honoring the overrides provided in `specific_paperformat_args`. This commit updates the conditional checks so that values from `specific_paperformat_args` correctly override the paperformat defaults even when the override is 0. This allows users to intentionally remove all margins and spacing defined on the report. Task-5079740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237284
This update prevents the creation of duplicate reversal and deferral entries when generating deferred entries from invoices. The change corrects an issue caused by a recent update to how month calculations are handled, ensuring journal entries are cleaner and more accurate. This improves the overall stability and clarity of financial reporting.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#100507
This update resolves an issue where website forms incorrectly displayed a 'null' placeholder when a field's type was changed. The fix ensures placeholders are empty, providing a cleaner and more user-friendly experience for website form users. This improves the overall quality and consistency of the website.
Original PR description
Steps to reproduce: 1. Add a form on the website. 2. Add a new field of type *selection*. 3. Change the field type from *selection* to *text*. → The placeholder is incorrectly set to the literal string `null` instead of being empty. This commit ensures the placeholder is not assigned the `null` string when changing field types. task-5383835
This update fixes a potential issue where reports could be printed multiple times, leading to unnecessary activity. The change ensures that websocket actions aren't duplicated by also checking for longpolling calls, streamlining the process and improving efficiency. This prevents wasted resources and ensures accurate reporting.
Original PR description
In order to prevent duplicate IoT actions, we now ensure that websocket actions have not already been called through longpolling. odoo/enterprise#100161 Forward-Port-Of: odoo/odoo#236917
This update fixes a potential issue where IoT reports could be printed multiple times. The change ensures that websocket actions are not duplicated by longpolling, streamlining report generation and avoiding unnecessary output. This improves efficiency and reduces potential errors.
Original PR description
In order to prevent duplicate IoT actions, we now ensure that websocket actions have not already been called through longpolling. odoo/odoo#236917 Forward-Port-Of: odoo/enterprise#100161
Features or functions removed from Odoo
This update removes outdated services automatically added when connecting to the Peppol network. These services (used primarily by Belgian users) were no longer relevant due to changes in Peppol standards and restrictions on user registration from Australia, New Zealand, and Singapore. This simplifies the system and reduces potential confusion.
Original PR description
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice &…
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version, - the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version. Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ... In the future we would like to handle the received services(formats) on IAP directly to handle change better. https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50 I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion. <img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" /> Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json