Wednesday, July 30, 2025
11 changes · 18.0
Enhancements to existing features
This update prepares Guatemala localization for a forthcoming electronic invoicing capability. It allows certain test VAT numbers for Guatemalan companies and adds a fuel-related accounting entry needed for local compliance workflows.
Original PR description
related enterprise PR: https://github.com/odoo/enterprise/pull/84036
The IoT Box homepage warning now states that the SSL certificate is invalid, without incorrectly mentioning a missing subscription. This avoids confusing users because a subscription is no longer required to obtain a valid certificate.
Original PR description
When the IoT Box doesn't have a valid ssl certificate, we used to display a warning telling that there is no valid subscription. As users don't need a subscription anymore to get a valid certificate, we now only tell that the certificate is invalid. Task: 4978644
Resolved issues and error corrections
This fix ensures disabled subtle input groups on website forms show a consistent disabled style, regardless of the input type or whether the label appears before or after the field. It improves visual clarity for users by making unavailable fields easier to recognize.
Original PR description
Prior to this commit, the disabled state of subtle input-group worked partially. Depending on the type of input and the position of the label (before or after the input), the disabled style was not correctly applied to the label. This commit adapts the style to cover all possibilities. task-4930086 | Before | After | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This updates the contributor license agreement record for the GitHub user shawkialaddin so it can be verified correctly. It helps ensure future contributions from this person can pass Odoo's required legal checks before merging.
Original PR description
### Description of the issue/feature this PR addresses: This PR is to add my Individual Contributor License Agreement (CLA) signature to the Odoo project. ### Current behavior before PR: My GitHub user `shawkialaddin` has not signed the CLA yet, so contributions cannot be merged. ### Desired behavior after PR is merged: The CLA signature is registered and verified by the CLA bot, allowing future PRs from `shawkialaddin` to pass the CLA check automatically. --- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Please squash on merge.
The Saudi e-invoicing localization now uses the correct exemption reason code for international passenger transport. This helps invoices align with local VAT reporting requirements and reduces the risk of incorrect tax documentation.
Original PR description
The code for The international transport of Passengers was wrong. It was VATEX-SA-34-1 instead of VATEX-SA-34-2. This commit fixes the code. task-id: 4949581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219301
Point of Sale orders paid with multiple methods now show the same payment method in both the order search view and the report. This reduces confusion when reviewing or grouping POS sales by payment method, while keeping the existing limitation that only one method is displayed for mixed payments.
Original PR description
Previously, orders with multiple payment methods showed different methods in the search view and the report. This remains a technical limitation of multi-method payments, but the behavior is now consistent. Steps to reproduce: ------------------- * In PoS create and validate an order paid by cash AND card * In the backend go to Reporting > Orders * Select Group By : Payement Method * Open the Report of your order > Observation: On the report, the method usually was the first one used but not in the search view opw-4851249
The test invoice file was updated so it uses a product that exists in the test setup. This ensures the tax prediction test validates the intended tax-matching behavior instead of passing for the wrong reason, reducing the risk of unnoticed regressions.
Original PR description
Previously, the test XML file included a product that did not exist in the test environment. As a result, on import the aml could not retrieve the product. Due to this, the _predict_taxes method in _onchange_name_predictive was invoked, which ended up assigning the correct tax. This caused the test to pass without actually verifying the behavior of the _predict_specific_tax. With this **PR** test xml has now been updated to properly focus on and validate the _predict_specific_tax method behavior. **task**-4943015 Enterprise PR - https://github.com/odoo/enterprise/pull/91224
Invoice legal document downloads now return the expected data format, preventing failures for customers or processes retrieving invoice files. The change also improves handling when multiple document file types are requested, making downloads more reliable.
Original PR description
`_get_invoice_legal_documents` should, and is expected to, return a dict. however, if called with `filetype = all`, it returns, because of `_get_invoice_legal_documents_all`, a list which breaks calling code as they expect a dict not a list, and this part of the code is not used anywhere nor tested. - remove the line causing `_get_invoice_legal_documents` to return a list. - make `download_invoice_documents_filetype` work with multiple filetypes no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue for French companies where removing the Delivery Address field from an invoice view could cause the system to crash. The invoice view now safely handles cases where that field is no longer present, improving reliability when customizing invoices with Studio.
Original PR description
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with…
The system will crash with an error when we try to remove the field 'Delivery Address' from the invoice view while in 'fr company'. **Steps to Produce:-** - Install `l10n_fr` and `web_studio` with demo data. - Switch to `FR Company`. - Go to `Invoicing > Customers > Invoices`. - Open any invoice > Toggle studio > Click on `Delivery Address` > and then click on `REMOVE FROM VIEW`. - Observe the error. **Error:-** `IndexError: list index out of range` **Root Cause:-** - At [1], the `_get_view` method unconditionally expects the `partner_shipping_id` field to be present in the invoice form view. - It performs an `xpath` search for the field and immediately attempts to access the first element of the result list. **Solution:-** - Now, if the `partner_shipping_id` field exists in the view, then the logic proceeds as before. If it's not found, the code block is simply skipped. [1]: https://github.com/odoo/odoo/blob/044833804c9e10048ec10d7e982c98c4f33f4cf4/addons/l10n_fr_invoice_addr/models/account_move.py#L16 **sentry-6746543069** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218974
The Italian Libro Giornale PDF report now keeps debit and credit columns visible even when journal line descriptions are very long. Long text wraps within its column instead of widening the table, making exported audit reports easier to read and use.
Original PR description
Steps to reproduce: 1. Install *l10n_it_reports* and work with an Italian company. 2. Create and post a customer invoice whose invoice line has a long description 3. Go to reports -> Journals Audit adn print the `Libro Giornale` in PDF Before this change, journal lines with long names or descriptions would force the table to grow beyond the page width, causing the Credit and Debit columns to be pushed out of view in the PDF. Now, Debit and Credit are always visible. Long descriptions should wrap inside their cell without changing the overall table width. OPW-4791233
This update prevents a translation export failure in the Swiss payroll ELM transmission module. It ensures automated translation processing works reliably on supported Python versions, reducing test and deployment interruptions.
Original PR description
… failure Steps to reproduce ================== - Use python 3.10 or 3.11 - Run the test `test_export_translatable_resources` with l10n_ch_hr_payroll_elm_transmission installed Unexpected logs found:…
… failure
Steps to reproduce
==================
- Use python 3.10 or 3.11
- Run the test `test_export_translatable_resources` with l10n_ch_hr_payroll_elm_transmission installed
Unexpected logs found: ['ERROR:odoo.tools.translate:Failed to extract terms from /data/build/enterprise/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_transmission_mixin.py Traceback (most recent call last):
File "/data/build/odoo/odoo/tools/translate.py", line 1293, in _babel_extract_terms
for extracted in extract.extract(extract_method, src_file, keywords=extract_keywords, options=options):
File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 325, in extract
for lineno, funcname, messages, comments in results:
File "/venv/main/lib/python3.10/site-packages/babel/messages/extract.py", line 487, in extract_python
value = eval(code, {'__builtins__': {}}, {})
File "<string>", line 2, in <module>
NameError: name 'month' is not defined']"
Cause of the issue
==================
Babel cannot extract translatable strings when f-strings are used inside `_()` in Python 3.10, resulting in a `NameError` during evaluation.
Solution
========
Move the f-string outside the _() call
runbot-163675
Forward-Port-Of: odoo/enterprise#91219