Daily updates from Odoo
Friday, November 21, 2025
29 changes · 18.0
Resolved issues and error corrections
This change prevents website page saves from crashing when an embedded code block is missing required attributes. Instead of failing with an internal error, the system now validates the content and raises a clearer message, making editing more reliable for website users.
Original PR description
Currently, an error occurs when saving a website page that contains an embedded element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes. **Steps to produce:** - Install the…
Currently, an error occurs when saving a website page that contains an embedded
element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes.
**Steps to produce:**
- Install the `website` module.
- Open the `Website` app and click `Edit`.
- Drag an `Embed Code` block and add one of the following examples:
`<span data-oe-field='name' data-oe-model='res.partner' />`
or
`<span data-oe-type='int' data-oe-model='res.partner' />`
- Try to `Save` it.
**Error:**
`TypeError: can only concatenate str (not 'NoneType') to str `
`KeyError: None`
**Root Cause:**
At [1], the code tries to concatenate `'ir.qweb.field.' + el.get('data-oe-type')`,
but when `data-oe-type` is missing, `el.get('data-oe-type')` returns `None`,
causing an `error`.
At [2], when the `data-oe-field` attribute is missing, the code
tries to access `Model._fields[field]`, resulting in an `error`.
**Fix:**
This commit adds validation for missing attributes in the embedded
element, ensuring a clear error message is raised instead of a crash.
[1]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L67
[2]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L71
sentry–6675421840Invoicing-only users in the India localization could hit an access error when creating or posting invoices. This update gives the invoicing group the read access it needs, so invoice processing works smoothly when the related accounting features are installed.
Original PR description
In India localization, invoicing-only users were getting an AccessError on `account.fiscal.year` when creating or posting invoices. This happened when both l10n_in_withholding and account_accountant modules were installed. Added missing read access for the invoicing group to resolve the issue. Reference computation: During computation of TDS/TCS, warning `compute_fiscalyear_dates` method is called https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/l10n_in_withholding/models/account_move.py#L124 In the `compute_fiscalyear_dates` method, it searches for 'account.fiscal.year' records https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/account_accountant/models/res_company.py#L162 As invoicing-only users don't have access to 'account.fiscal.year' records It will raise AccessError Task-5346551
This fix makes website anchor links behave as users expect when “Open in New Window” is enabled. Instead of staying in the same tab and scrolling on the page, the link now opens in a new tab while still jumping to the selected section.
Original PR description
Steps to Reproduce: 1. Create an anchor link for any dropped snippet. 2. Insert the link through the link popover. 3. Enable the "Open in New Window" option. 4. Click on Save. 5. Click on the link. Issue: Even though the "Open in New Window" option is enabled, the page scrolls in the same tab instead of opening in a new window and scrolling to the targeted view. Reason: When an anchor link has target="_blank", `ev.preventDefault()` was still being called, which prevented the browser from performing its default behavior of opening the link in a new tab. Fix: Removed `ev.preventDefault()` for such links, as the expected behavior is to open them in a new tab whenever target="_blank" is set. Additionally, the offcanvas mobile-specific logic has been removed, as it is no longer necessary now that `ev.preventDefault()` is no longer used. task-5104027 Forward-Port-Of: odoo/odoo#228787
This change prevents Odoo from showing an unexpected traceback when Egypt’s ETA rejects an e-invoice download request and the response cannot be read as JSON. Instead, the error is now handled properly, resulting in a smoother and clearer user experience when a request fails.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update fixes a layout issue that could hide or break the exchange rate section on printed invoices when multiple GCC localization apps are installed together. It helps ensure invoices render correctly for affected companies, especially when using a foreign currency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Certification lines now refresh their status color correctly when a certificate passes its end date. This ensures the Certifications report reflects the current situation without requiring any manual change.
Original PR description
**Steps to reproduce:** 1. Install `hr_skills_survey` 2. Go to Employees > Reporting > Certifications. 3. Create a certification line with a future end date → record shows in black. 4. Change the system date to after the end date. **Issue:** - The line color is not updated when time passes. **Cause:** https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/models/hr_resume_line.py#L17 https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/views/hr_employee_certification_views.xml#L7 - The color was based on the stored computed field `expiration_status`, which only depends on `date_end`. Since `date_end` does not change with time, the field value is not recomputed daily. **Solution:** - Introduce a non-stored computed field `expiration_status_ui`, depending on `date_end` and use it in the view to update expiration_status. opw-5065185
This fix prevents the system from mixing different products when calculating average cost during stock valuation. As a result, validating returns and related deliveries works reliably, avoiding an error that could block normal warehouse operations.
Original PR description
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product. The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error. Steps to reproduce: - Create storable products P1 and P2: - Category: AVCO - P1 UoM: Unit - P2 UoM: Dozen - Create a sale order with 1 unit of P1 - Confirm the SO - Open the generated picking - Duplicate it → a new picking is created and still linked to the same SO - Change the product on the duplicated picking to P2 - Confirm and validate it - Create a return on this picking and validate it - Go back to the original picking of P1 and try to validate it Problem: A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)” This fix ensures that average price is computed only using stock moves belonging to the same product. opw-5027089
This change fixes an access issue that prevented invoicing-only users from opening or creating invoices when a TDS/TCS warning was present. As a result, teams with limited invoicing access can continue their work without unexpected permission errors.
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
This fix makes the vendor on-time delivery rate display the same value in the smart button and the graph. It now calculates against the original purchase order quantity, so partial receipts and duplicated receipts no longer distort the result.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#225529
The Documents settings page now shows clearer labels and helper text for each access right option. This makes it easier for administrators to understand what each permission does and choose the right setting with confidence.
Original PR description
This commit fix the label of documents access rights which now shows a helper for each documents res.groups. Task-5186096
Exchange rates from the Swiss Federal Tax Administration are now saved with the correct publication date instead of the later validity date. This ensures the dates shown in Odoo match the actual rate information received from the source.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127
The Italian “Libro Giornale” report was affecting all journal reports in some cases, which could remove journal names from exported PDFs. This update limits the custom formatting to the correct Italian report only, so other companies’ journal reports display properly again.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520
This change restores the expected payment setup for standard ISO 20022 bank transfers. Payments now automatically use the NURG service level as before, which helps ensure the correct processing of non-SEPA transactions.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e
This change makes Odoo more reliable when linking incoming supplier bills to their related purchase orders. It now ignores tiny price differences that are within the normal product price rounding, so valid matches are no longer missed because of insignificant decimal variations.
Original PR description
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is…
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232527
This update prevents the interface from displaying the word “undefined” when a hidden section is skipped during page rendering. In full-size forms, it ensures empty spaces stay clean instead of showing stray text where buttons or controls would normally appear.
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#236461
This update corrects the French Balance Sheet so it stays balanced when using the 2024 chart of accounts. It restores missing income and expense amounts in the retained earnings calculation, which helps ensure accurate financial reports for companies using the French localization.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801
This update corrects missing settings on several Philippine tax tags so they are treated properly in tax calculations. As a result, tax reports will no longer show incorrect figures for affected cases.
Original PR description
This commit sets tax_negate to true to (-QAPA, -QAPB, -SAWTA, -SAWTB). They were missing and impacted a tax report falsely. opw-5157090
This fix prevents parent folders from automatically expanding when a user opens a folder inside them. It makes folder navigation in Documents more predictable and keeps the folder tree easier to scan.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161
Users can now create reordering rules for a product in one company even if that product has a kit bill of materials defined in another company. This fixes an incorrect validation error and prevents kit settings from one company from blocking operations in another.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
This update stops users from changing the product on combo item lines by mistake or misuse. Description edits are still possible, but users now need to hide the product-related columns first, which helps keep combo orders accurate.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes).
This fix allows users with invoicing-only permissions to create and open invoices even when a TDS/TCS warning is set on the chart of accounts. It removes an access error that was blocking normal invoicing work for those users.
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
This update prevents import failures when users upload CSV files encoded in UTF-16. Instead of crashing with a low-level decoding error, Odoo now shows a clearer warning, making it easier to understand and resolve the problem.
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
For Canadian companies that close their fiscal year on a date other than December 31, the tax report now lets them choose a different start date. This helps ensure annual filings are calculated on the correct period and avoids issues with closing dates.
Original PR description
If a user from CA has a fiscal year on something other than the 31/12 and needs to return annually, he can't do his closing on the right bounds. We now allow CA to show the field to be able to shift it, as government allow it. Later, we will change the heuristic to be smarter to show it as soon as it may cause issue. opw-5193999
This fix restores the missing date scope settings on some Balance Sheet lines used in cross-report links. As a result, the report will show figures for the intended period more consistently, reducing the risk of confusing or incomplete financial comparisons.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
The German DATEV export now correctly reflects bills where the tax amount was manually adjusted. This prevents mismatches between what users see in accounting reports and what gets exported for tax and audit purposes.
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 / 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#98684
The system now uses the current official state code for Odisha in India. This avoids incorrect location data when creating contacts and related documents like sales 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
The planning analysis report now correctly checks whether a shift falls within working hours before counting it in a given month. This prevents hours from being wrongly assigned to the next month when a shift ends outside normal working time.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This fix restores the ability to edit timesheet entries that are linked to an invoice after that invoice has been reversed. It helps teams correct recorded hours even when the original billing document has been canceled and replaced by a credit note.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#234108 Forward-Port-Of: odoo/odoo#201921
This change fixes how Mail’s automated tests simulate browser environments. It ensures the test tool is used with the intended device/platform values, which helps keep test behavior accurate and reliable.
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.