Daily updates from Odoo
Saturday, November 22, 2025
12 changes · saas-18.4
Resolved issues and error corrections
This update corrects the Balance Sheet report so its linked cross-report lines respect the selected date range. As a result, the report shows more accurate figures when users compare or drill into balances for a specific period.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
Odoo now uses the updated official state code for Odisha in India. This helps ensure customer details and sales documents use the correct regional information and avoids mismatches when creating orders.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
This update prevents a crash when reopening the website theme editor after using some Google Fonts that only offer one font weight. It ensures those fonts are loaded correctly so users can continue editing the theme without interruption.
Original PR description
Steps to reproduce: =================== 1. Edit the website theme and set an external font, e.g., UnifrakturCook. 2. Save, exit, then reopen the editor and go to the Theme tab. → Traceback occurs. Cause: ====== Some Google Fonts (e.g., UnifrakturCook) only provide a single weight (700). When fetching the font, html_builder does not request a specific weight, so Google Fonts attempts to return the default set, including 300. Since that weight does not exist for these fonts, Google Fonts responds with an error, leading to the traceback. This issue is same to the one fixed here: https://github.com/odoo/odoo/commit/f843c591c0377e0dab1a1f0cfaca36c1981c8880 but the fix was not ported during refactoring. opw-5259891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an error that could appear when a user had several companies selected and refreshed the OSS mapping for one active company. The refresh action now correctly runs on the intended company, preventing a crash and keeping the workflow usable.
Original PR description
To reproduce: - Activate multiple companies in the selector - Enable OSS on the active company - Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies. Forward-Port-Of: odoo/odoo#236103
This fix ensures the annual corporate tax return uses the company’s actual fiscal year dates when a fiscal period is longer than one year. As a result, the tax return dashboard will show the correct closing period and deadline, avoiding an incorrect return being created for the wrong year.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432 Forward-Port-Of: odoo/enterprise#100034
This update fixes how the mail module simulates browser settings in automated tests. It ensures the test helper is used with the right platform information, which helps keep test behavior accurate and prevents misleading results.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/odoo#236837Importing CSV files encoded in UTF-16 now fails with a clearer warning instead of a technical decoding error. This makes it easier for users to understand what went wrong and correct the file or encoding setting.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266 Forward-Port-Of: odoo/odoo#226023
This fix ensures German Datev export files reflect the tax amount that users manually adjusted on supplier bills. Before this change, the exported totals could still use the original tax value, which led to mismatches between the accounting report and the export file.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100086 Forward-Port-Of: odoo/enterprise#98684
This change prevents an access error that could block invoicing-only users from creating or opening invoices when a TDS/TCS warning is enabled. It allows the warning to work without requiring full accounting access, so business users can continue invoicing normally.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551 Forward-Port-Of: odoo/odoo#236965 Forward-Port-Of: odoo/odoo#236896
This update prevents hidden parts of a form from displaying the word “undefined” when they are not meant to be shown. It keeps those areas empty instead, which avoids confusing visual glitches in forms and button sections.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236724 Forward-Port-Of: odoo/odoo#236461
This update restores correct social media statistics by adapting to Facebook’s deprecated metrics. It keeps account and post reporting working even though some old data points were removed or renamed by Facebook, which helps prevent missing or incorrect trends in the dashboard.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
When an invoice is duplicated, it will no longer reuse the original sales order as its source document. This prevents copied invoices from showing misleading sales-order information and avoids errors in e-invoice exports that rely on that field.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656