Daily updates from Odoo
Friday, August 29, 2025
16 changes · master
Resolved issues and error corrections
Fixed an issue where starting two IoT WebRTC connections almost at the same time could cause the connection to fail. The update prevents duplicate connection attempts while one is already opening and adds test coverage to reduce the risk of this happening again.
Original PR description
If two calls are made to open a WebRTC connection within a short space of time, they will both try to open a new connection causing a failure. This commit fixes the issue by checking to see if a connection is currently opening before continuing. It also adds a unit test for this scenario.
UK tax report submissions to HMRC now include the correct obligation ID. This prevents submissions from failing or being sent with missing reference information, improving reliability for UK tax filing workflows.
Original PR description
Issue: Prior to this commit, when sending a tax report to HMRC, the obligation ID was undefined Fix: sending the appropriate obligation ID opw-4965620 Forward-Port-Of: odoo/enterprise#91735
The Spanish SME balance sheet now avoids counting certain current financial investment accounts twice. This ensures reported investment amounts match the underlying accounting entries, improving confidence in financial statements.
Original PR description
**Issue**: * Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in…
**Issue**: * Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in balance_pymes_line_12500_sub_balances formula **Root Cause**: * Account codes 551 and 5525 were included in BOTH: 1. Line 12500 sub_balances (unfiltered account_codes expression) 2. Line 12500 sub_debits (domain expression with sum_if_pos filter) * This double-counting within the same line caused financial investment amounts to appear twice in the balance sheet **How to Reproduce**: 1. Create Spanish company with 'es_pymes' chart of accounts 2. Post journal entries to accounts 551 or 5525 (current financial investments) 3. Generate 'Balance Sheet - SMEs (ES)' report 4. Observe amounts in line 'V. Current financial investments' are exactly doubled compared to account balances 5. Click on the doubled amount - shows underlying transactions sum to half the amount **Fix**: * Removed account codes 551 and 5525 from balance_pymes_line_12500_sub_balances * These accounts are properly handled by the sub_debits expression * Each account is now counted only once within the line opw-4983300 Forward-Port-Of: odoo/enterprise#93052
Quality checks on manufacturing orders can now proceed without users first entering the producing quantity. This removes an obsolete validation that is no longer needed because invalid manufacturing quality point setups are already prevented elsewhere.
Original PR description
This commit reverts the change from: [PR](https://github.com/odoo/enterprise/commit/51a9b38), which had introduced a `UserError` that occurs when creating a quality point with operation type `Manufacturing` having control per `quantity`. Revert is done since this [PR](https://github.com/odoo/enterprise/pull/67780) now prevents creating quality points with operation type `Manufacturing + control per quantity`, which makes the original bugfix PR unnecessary and has become dead code. After this commit, quality checks on manufacturing orders no longer require setting the producing quantity first. Task ID: [4915067](https://www.odoo.com/odoo/project/966/tasks/4915067)
Spreadsheet list headers are now stored consistently so pivots keep working when users open the same spreadsheet in different languages. This prevents dashboards and custom spreadsheets from breaking for multilingual teams and also standardizes dashboard file formatting for easier maintenance.
Spreadsheet list headers now stay consistent regardless of each user's language settings. This prevents pivots and dashboards based on list columns from breaking when opened by colleagues using a different language.
Original PR description
Current issue: Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list. Alice chooses the pivot dimensions based…
Current issue: Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list. Alice chooses the pivot dimensions based on the columns headers, which are the translated(!) field display names. Now Bob opens the spreadsheet. => the pivot doesn't work because the dimension are specified using the field names in English, but they cannot be found because they are in French in the spreadsheet. The issue is that `ODOO.LIST.HEADER` returns the translated field string. One solution would be drop `ODOO.LIST.HEADER` completely and just hard-code the string values when the list is inserted. But users use it to add fields after, and then auto-fill it. Also, being easily able to know which cells are list headers is helpful to display "widget" like the sorting widget (task 4543812) Other thing to consider: currently, when users are creating their own spreadsheet/dashboard, there's a mix of languages: what they manually type in cells, in their language (untranslated obviously) and the result of ODOO.LIST.HEADER, which is translated. Task: 4805206
Point of Sale badge printing now loads the needed badge format information again. This restores badge printer functionality for event check-ins and reduces manual work for staff using PoS at events.
Original PR description
Due to an oversight in odoo/enterprise#83021, printing badges using the badge printer from POS was not working. This commit fixes the issue by restoring the `badge_format` field to the list of fields loaded in the POS. Forward-Port-Of: odoo/enterprise#93365
GSTR document summaries now ignore invoices that no longer have a valid sequence number. This prevents report generation errors and ensures only properly numbered invoices are included.
Original PR description
_* = l10n_in_reports_gstr_document_summary Issue: - The GSTR document summary included all invoices that were posted or cancelled with posted_before = True. - If a user manually cleared the invoice sequence (set it to null), such invoices were still picked up. - This caused errors during summary generation since those invoices no longer had valid sequence numbers. Fix: - Adjusted the document summary logic to only include invoices with a valid sequence number. - Ensures that entries without a sequence are ignored, even if they were once posted. Impact: - Prevents errors when generating GSTR document summaries. - Guarantees that only valid, numbered invoices are included in reports. opw-5005048 Forward-Port-Of: odoo/enterprise#93039
This fixes an issue in Barcode receipts where removing scanned serial-number lines could remove the wrong item. Users can now decrement and re-enter serial numbers without false duplicate warnings, reducing receiving errors for tracked products.
Original PR description
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines has the lot_name fixed on the first scanned serial_number. So when decrementing the last_line, it will always use the virtual_id of the first serial_number scanned, leading to decrementing the wrong serial number. It starts showing that the next scanned number is already used, because it wasn't properly removed in the first place. opw-4646765 Forward-Port-Of: odoo/enterprise#89987 Forward-Port-Of: odoo/enterprise#88130
Portal users receiving published planning shift emails are now sent to the correct planning page instead of the portal dashboard. This helps external or limited-access users view their schedules directly from email without confusion or extra navigation.
Original PR description
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on…
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on View Your planning - Notice you are redirected to the portal dashboard home ### Cause: Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26 ### Fix: We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view opw-5045746 Forward-Port-Of: odoo/enterprise#93359 Forward-Port-Of: odoo/enterprise#93333
Recurring subscription orders with timesheet-based services are no longer incorrectly treated as free when work has already been delivered. This ensures invoices are generated for delivered service work even when the original order quantity or recurring amount is zero, helping prevent missed revenue.
Original PR description
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product…
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product and set the qty to 0 - Create a Helpdesk ticket and link it to the SO - Record some timesheets in this SO - Run the cron for generating recurring invoices - Notice no invoice will be created for the SO and it will be considered as free renewal ### Cause: When trying to create a recurring invoice we check if the invoice that will get generated is free by checking the MRR and the total amount of the SO and if one of them are 0 we will flag this invoice as free so we won't generate it ### Fix: We check if the order lines to be invoiced is invoiced based on delivery and they have delivered quantity already and if so we create the invoice even if the MRR and the total amount is equal 0 opw-4990478 Forward-Port-Of: odoo/enterprise#93245 Forward-Port-Of: odoo/enterprise#93115
Managers can now access VoIP call records for employees across their full reporting line, not just direct reports. This fixes incomplete visibility for teams with multiple management levels and helps managers review relevant call activity more reliably.
Original PR description
This commit fixes the record rules that specifies the users that can read phone calls made through VoIP. Currently, managers can only access call records of their direct subordinates. They should have access also to calls made by employees that are managed by their direct subordinates. This commit fixes that. Task-5033984
The fix ensures that signing request email buttons direct recipients to the website of the company that sent the request, rather than defaulting to another company’s website. This reduces confusion for signers and helps avoid business or legal issues caused by documents appearing under the wrong company.
Original PR description
According to a ticket, when you have 2 companies and send a sign request from the second one, the button in the email received from the signer redirects to the website of the first company. This may cause confusion and may have legal implications. This PR aims to fix the problem by correctly targeting the right website. Task & ticket: 4976533
The work entry split action in the Gantt view now opens a confirmation form instead of trying to split immediately. This helps HR users review the split details first and prevents incorrect or failed split actions.
Original PR description
This commit fixes how the split button behaves in the Gantt view of the work entry. Instead of calling the ORM function upon clicking the split button, the split button now opens a `FormViewDialog`. The save button in the dialog is modified so that, instead of saving the record data, it calls the `action_split` function that handles the splitting logic. The context is used to open the dialog with a custom form view that has read-only fields, and the form is populated with the existing work entry data, except for the duration, which is set as half of the existing work entry duration. task-5043857
GSTR2B reconciliation now skips vendor bills that do not include any taxes. This prevents bills that vendors likely did not file from appearing in the reconciliation process, making Indian GST reporting more accurate.
Original PR description
Before this commit- We included the Vendor bills without taxes for GSTR2B reconciliation After this commit- We exclude the Vendor bills without taxes for GSTR2B Because if no tax is there on the bill it means wasn't filed by the Vendor as well task-5023013 Forward-Port-Of: odoo/enterprise#93373 Forward-Port-Of: odoo/enterprise#92866
The subscription invoicing process now skips subscriptions linked to archived companies. This prevents hidden or inactive company records from continuing to generate recurring invoices unexpectedly.
Original PR description
Currently, when a company which has recurring orders (subscriptions) active is archived, the cron still periodically invoices them as usual but the user is not able to see it because they don't show up in the views. To avoid having to unarchive the comany and check every subscription one by one, this PR aims at making the cron ignore any subscription tied to an archived company, as intended. The only modified cron is the one that creates invoices since the other one of interest (the one that sends reminders) operates only on invoiced orders, which we avoid having with this change. Also added a test to ensure that if the company related to a subscription sale order is archived, the cron won't invoice it. Task: 4947107