Daily updates from Odoo
Thursday, November 6, 2025
11 changes · saas-18.2
Resolved issues and error corrections
This update fixes two issues in the Australian TPAR report. Exported country names now use the correct plain text value, and PDF reports now include the information needed to render properly, preventing export failures.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990This change corrects how prices and weights are rounded before sending shipment data to DHL. It prevents validation failures caused by tiny floating-point precision errors, helping deliveries go through without unexpected errors.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98819 Forward-Port-Of: odoo/enterprise#96012
The appointment booking flow no longer stops at a hardcoded limit of 12 for resource capacity. A new global setting lets businesses define the maximum capacity available in the website booking options, so larger resources can be handled correctly.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#94935
The account reports info popover now uses a lighter text color in dark mode. This makes the displayed formula easier to read for users working in the dark theme, especially in debug mode.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
This fix stops signing request emails from being sent again when a contact’s email address is changed only in letter case, such as from lowercase to uppercase. It prevents duplicate emails and avoids confusing recipients with repeated signing requests for the same document.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
The POS floor plan will only show new table bookings that match the appointment type configured for that POS setup. This prevents bookings from appearing and then disappearing after refresh, and avoids sending notifications when no booking type is set. When Table Booking is turned off, the related appointment type is now cleared automatically to keep settings consistent.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v17.0: [#93714](https://github.com/odoo/enterprise/pull/93714) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset. Forward-Port-Of: odoo/enterprise#93636
This update corrects automated tests for the accounting reports module after a previous change caused them to fail. It helps keep the reporting feature reliable and ensures future updates can be validated correctly.
Original PR description
See https://github.com/odoo/enterprise/commit/5291d0249ba925182fb9e670f9b46b9e57bda00c Forward-Port-Of: odoo/enterprise#98891
This update prevents Shiprocket from failing when GST-specific tax tags are not available, which can happen in installations without the Indian localization module. It also makes the related test more reliable by explicitly using a 15% tax, ensuring the behavior stays consistent across environments.
Original PR description
Some other test adds a fiscal position with tax mapping. This creates 2 problems 1. The new taxes have a tag, which means we evaluate the right hand of…
Some other test adds a fiscal position with tax mapping. This creates 2 problems
1. The new taxes have a tag, which means we evaluate the right hand of
https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239
However, since l10n_in is not installed,
`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`
does not return anything (False is not a fallback)
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588
So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558
2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true
Solution
-----
1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test
-----
runbot-232692
Forward-Port-Of: odoo/enterprise#97998Completed manufacturing orders can no longer be canceled by mistake. Instead, the system now shows an error message, avoiding the accidental cancellation of related stock movements and keeping manufacturing records consistent.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98758This change prevents an access error that could appear when opening the Documents app after a company was archived. It ensures users only load folders they are still allowed to access, making the app more reliable in multi-company setups.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278 Forward-Port-Of: odoo/enterprise#96817
This fix restores the ability to post Italian tax closing entries when the tax period is set to quarterly. Previously, the system incorrectly blocked these returns by applying a rule meant only for monthly filings, which could prevent users from completing a valid quarterly closing.
Original PR description
A [previous PR](https://github.com/odoo/enterprise/pull/86642) improved the XML export of tax returns with Italian localization. This introduced a bug if the tax period is set quarterly. Currently, it prevents a tax return move from being posted if it detects previous tax closings, but there are none in the previous month. This should only be the case if the tax period is set monthly. Steps to reproduce on runbot: - Install the l10n_it_xml_export module - Switch to an Italian company and set the tax period to `quarterly` - Create a closing entry for the previous quarter - Try to create a closing entry for the current quarter Related ticket: opw-5156791 Forward-Port-Of: odoo/enterprise#99002 Forward-Port-Of: odoo/enterprise#98241