Tuesday, June 3, 2025
8 changes · 18.0
Resolved issues and error corrections
This fixes report footers so documents without a tagline no longer show a large empty space. It also improves detection of empty footer content, helping reports display the standard footer layout consistently across affected localization templates.
Original PR description
commit https://github.com/odoo/odoo/commit/695b429d09887debe1a58e92abfd7e738350061d reworked the footer style but on boxed and bold if there is no tag line, it uses a col-8 that let a big empty space. Also it uses a wrong t-if condition on an html field. It should use is_html_empty since the field could contains empty tags (<br>) Fallback on standard template for report without report_header We keep a duplicate of class and t-attf-class in order to have a valid override of the template Fix l10n template to reduce the xpath and match the fix. Keeping the o_footer_content in both class for override and t-attf-class since `ir_qweb.py:def _compile_directive_att` ignore class attribute when t-attf-class is set opw-4618652
This fixes an issue in the HTML editor where double-clicking at the end of a link could place new text outside the link instead of inside it. Users editing website or document content can now extend linked text more reliably, reducing formatting mistakes.
Original PR description
Correct the double click selection at the end of a link to allow the new text input to be inside the link. task-4801000 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change updates a product import test so it uses the correct file type information for older Excel files. It prevents false test failures in environments with Excel-reading libraries installed, helping keep product import validation reliable.
Original PR description
### Description of the issue/feature this PR addresses: Given https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90 Then…
### Description of the issue/feature this PR addresses:
Given
https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90
Then `test_import_product_demo_xls` incorrectly pairs .xls file extension with mime type `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`
### Current behavior before PR:
Tests in the product module fail when openpyxl is installed.
```
2025-05-19 15:08:32,243 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.supplierinfo]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
2025-05-19 15:08:32,268 1 WARNING odoo odoo.addons.base_import.models.base_import: Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet').
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 429, in _read_file
return getattr(self, '_read_' + file_extension)(options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 509, in _read_xlsx
book = load_workbook(io.BytesIO(self.file or b''), data_only=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 344, in load_workbook
reader = ExcelReader(filename, read_only, keep_vba,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 123, in __init__
self.archive = _validate_archive(fn)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 95, in _validate_archive
archive = ZipFile(filename, 'r')
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/zipfile/__init__.py", line 1349, in __init__
self._RealGetContents()
File "/usr/lib/python3.12/zipfile/__init__.py", line 1416, in _RealGetContents
raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
2025-05-19 15:08:32,269 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.template]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
```
### Desired behavior after PR is merged:
Tests pass even when openpyxl is installed.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix improves how Odoo's web testing tools handle errors during page element searches. It ensures internal cleanup happens reliably, reducing confusing follow-up errors for developers maintaining web features.
Original PR description
Before this commit, 'queryX' functions in Hoot would supposedly cleanup internal global variables on error thrown by the helpers. However, this only took into account the errors explicitly thrown, and NOT those that were thrown by other methods/native code, such as invalid native query selectors. This commit introduces a new internal method to "guard" exposed 'queryX' helpers, to properly cleanup internal variables on any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the HTML editor from crashing in Firefox when users press Enter rapidly while editing a To-do. It improves reliability by handling fast content changes safely, so users no longer see an error traceback during normal editing.
Original PR description
### Browser: Firefox ### Steps to reproduce: - Create a To-do. - Press Enter repeatedly and quickly. - A traceback occurs. ### Description of the issue/feature this PR addresses: - Pressing Enter quickly remove elements before their hooks are updated, causing hookElement to be undefined and triggering a crash. ### Desired behavior after PR is merged: - Traceback no longer occurs. task-4766147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a misleading warning that appeared when users created a delivery operation type even though a warehouse already existed. The change makes the dropshipping check use the current operation type, preventing unnecessary confusion during inventory configuration.
Original PR description
…compute **PROBLEM** When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one. **STEPS TO REPRODUCE** 1. On a…
…compute **PROBLEM** When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one. **STEPS TO REPRODUCE** 1. On a fresh database, install stock with drop shipping and storage locations enabled. 2. Create a new operation type and set the type to Delivery. 3. You will receive the following warning, despite an existing warehouse: ``` Please create a warehouse for company <company> ``` **CAUSE** https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316 https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74 When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed. Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False. **FIX** In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`. opw-4603495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian Acerta payroll export now handles a missing Acerta Affiliation Number more gracefully instead of crashing when users generate an export file. This helps payroll teams understand or resolve missing setup information without encountering a technical error.
Original PR description
When Acerta Affiliation Number is unset and user tries to generate export file, A traceback will appear. Steps to reproduce the error: - Install ``l10n_be_hr_payroll_acerta`` module and switch to…
When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.
Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button
Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.
sentry-6620429585This fix prevents Indonesian payroll payslips from crashing when the period start or end date is cleared. Users can edit payslip periods more safely without triggering an unexpected error.
Original PR description
Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period. **Steps to Reproduce** 1) Install **l10n_id_hr_payroll module**. 2) Create a new **Pay-Slip**. 3) Remove **Date** from **Period** **Error:** `AttributeError: 'bool' object has no attribute 'month'` **Root Cause:** The `_compute_l10n_id_include_pkp_ptkp` method at [1] assumes that `date_to` and `contract_id.date_end` are always set and valid. If either of them is missing (False), accessing `.month` or `.year` causes an error. [1] - https://github.com/odoo/enterprise/blob/34aa0ffb82c1bd7c90b4cb161ea515f2cad8e65f/l10n_id_hr_payroll/models/hr_payslip.py#L87 **Solution:** This commit prevents the computation from failing when `slip.date_to` and `slip.contract_id.date_end` fields are unset by adding a conditional check to ensure that both fields are valid date objects before accessing their `.month` and `.year` attributes. sentry-6608982173