Daily updates from Odoo
Saturday, August 9, 2025
10 changes
5 changes
Resolved issues and error corrections
This update fixes internal tests so they pass consistently when an optional file-detection library is installed. It helps keep quality checks stable across environments without changing customer-facing behavior.
Original PR description
Those tests are failing when python-magic is installed. Since 26f9c82b99 Odoo > saas-18.4 has this lib as a requirement and comes with appropriate fixes. This commit adapts some test for versions prior to saas-18.4 to also work when the python-magic lib is installed. Forward-Port-Of: odoo/odoo#221408 Forward-Port-Of: odoo/odoo#221045
This fixes an installation failure in the Spanish VeriFactu e-invoicing module when certain optional tax records have been removed. Businesses can now install the module more reliably without being blocked by a validation error related to missing tax setup.
Original PR description
In case some taxes for which we specify Applicability info (field `l10n_es_applicability`) do not exist the module can not be installed. I.e. the `_l10n_es_edi_verifactu_post_init_hook` raises. Reproduce 1. Install `l10n_es` without installing `l10n_es_edi_verifactu` 2. Delete tax with xmlid `account_tax_template_s_iva_e` (sales tax with description "VAT 0% export (services)") 3. Install `l10n_es_edi_verifactu` 4. A "Validation Error" appears ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax (account.tax) Field: Tax Name (name) ``` opw-5003231 opw-4996685 opw-4999922 Forward-Port-Of: odoo/odoo#222385 Forward-Port-Of: odoo/odoo#222225
Invoice PDFs now handle very long product descriptions more reliably when line tables continue onto another page. This prevents descriptions from overlapping the table header, making printed invoices clearer and more professional for customers.
Original PR description
**Steps to reproduce**: 1. Install the `account` module. 2. Create a Invoice using this any product. 3. add long descripition (approx. 40-45 lines). 4. Print the PDF of Invoice (via gear icon).…
**Steps to reproduce**: 1. Install the `account` module. 2. Create a Invoice using this any product. 3. add long descripition (approx. 40-45 lines). 4. Print the PDF of Invoice (via gear icon). **Observation**: The long product description overlaps with the table header when the table spans multiple pages in the generated PDF. **Issue**: wkhtmltopdf does not handle multi-page table headers properly by default. causing header/content overlap when the table breaks across pages. **Solution**: Apply a known wkhtmltopdf workaround by explicitly setting: `<thead style='display: table-row-group;'>` This ensures headers will not repeat same as this. [#53909](https://github.com/odoo/odoo/pull/53909) before: <img width="818" height="231" alt="image" src="https://github.com/user-attachments/assets/8bcc6ced-5911-4abd-b91e-97ffa8fb735e" /> after: <img width="821" height="253" alt="image" src="https://github.com/user-attachments/assets/2ccc6995-c239-4beb-8f68-53d548b7f2f2" /> opw-4982735 Forward-Port-Of: odoo/odoo#222286 Forward-Port-Of: odoo/odoo#221681
This fixes a mismatch in the test setup for importing spreadsheet files, so the test behaves consistently across environments with different file detection tools installed. It reduces false test failures and helps keep account import quality checks reliable.
Original PR description
[FIX] account_base_import: fix mime type The `test_duplicate_journals_import` test fails when the magic lib is present. While the `xlsx` detection is supported, the test calls the import wizard with `xlsx` files but `application/vnd.ms-excel` as the file type which is for `xls` files. With this commit, the appropriate file type is given and the test works in all cases. (tested with Docker16, PureNoble and PureBookworm docker files) Forward-Port-Of: odoo/enterprise#91450 Forward-Port-Of: odoo/enterprise#91267
Rental order confirmation now continues processing planning shifts even when one line has no available resource. This prevents shift creation from stopping early and helps ensure all eligible rental order lines are handled correctly.
Original PR description
Before this commit, when rental order containing a plannable rental product is confirmed, some shifts will be generated according to the rental order lines with such product. The problem is when there is no available resource, the method in which we expect to return vals list of planning.slot model will return vals because it will break the loop instead of continuing to the next iteration. This commit makes sure the `_planning_slot_vals_list` always return list of vals.
3 changes
Resolved issues and error corrections
This fix updates internal mimetype tests so they pass whether or not the optional python-magic library is installed. It helps keep automated checks reliable across different environments without changing customer-facing behavior.
Original PR description
Those tests are failing when python-magic is installed. Since 26f9c82b99 Odoo > saas-18.4 has this lib as a requirement and comes with appropriate fixes. This commit adapts some test for versions prior to saas-18.4 to also work when the python-magic lib is installed. Forward-Port-Of: odoo/odoo#221408 Forward-Port-Of: odoo/odoo#221045
A test for importing duplicate accounting journals now uses the correct spreadsheet file type. This prevents false failures in environments with additional file detection libraries installed, making automated checks more reliable without changing user-facing behavior.
Original PR description
[FIX] account_base_import: fix mime type The `test_duplicate_journals_import` test fails when the magic lib is present. While the `xlsx` detection is supported, the test calls the import wizard with `xlsx` files but `application/vnd.ms-excel` as the file type which is for `xls` files. With this commit, the appropriate file type is given and the test works in all cases. (tested with Docker16, PureNoble and PureBookworm docker files) Forward-Port-Of: odoo/enterprise#91450 Forward-Port-Of: odoo/enterprise#91267
The Czech VIES summary report now counts invoices instead of invoiced quantities, groups records more appropriately, and rounds totals to whole Czech crowns. This helps businesses submit more accurate VAT summary reporting in line with official requirements.
Original PR description
There are some errors in the VIES summary report fixed here:
1. The supply number is not the quantity invoiced, it is the
number of invoices
2. There was some confusion between the terms "supply transaction"
and "supply code", with "supply code" not being used
in this report (but still in Python code to avoid breaking stable versions)
3. We were considering journal items, whereas it is preferable
to group them by journal entry
4. The total value is rounded up to the nearest whole crown (Czech currency)
Here is a link to the documentation:
adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV
where pln_hodnota is the total value; pln_pocet is the supply number; and k_pln_eu is the supply transaction.
opw-4688616
Forward-Port-Of: odoo/enterprise#91891
Forward-Port-Of: odoo/enterprise#882791 change
Resolved issues and error corrections
This fixes an internal test setup for account import so spreadsheet files are identified with the correct file type. It helps keep automated validation reliable across environments where extra file detection tools are installed, with no expected impact on day-to-day users.
Original PR description
[FIX] account_base_import: fix mime type The `test_duplicate_journals_import` test fails when the magic lib is present. While the `xlsx` detection is supported, the test calls the import wizard with `xlsx` files but `application/vnd.ms-excel` as the file type which is for `xls` files. With this commit, the appropriate file type is given and the test works in all cases. (tested with Docker16, PureNoble and PureBookworm docker files) Forward-Port-Of: odoo/enterprise#91450 Forward-Port-Of: odoo/enterprise#91267
1 change
Resolved issues and error corrections
Fixes several issues in Spain’s VeriFactu compliance flow, including cancellation handling, refund classification, and point-of-sale refund links. This helps ensure Spanish invoices and POS transactions are reported with the correct customer and document information, reducing validation errors and compliance risk.
Original PR description
- Use the right function instead of `button_cancel`. - Fix "is_simplified" in case of refund. Only `R5` should be simplified. For R1 to R4 we need to set the partner info in the JSON / XML…
- Use the right function instead of `button_cancel`.
- Fix "is_simplified" in case of refund. Only `R5` should be simplified.
For R1 to R4 we need to set the partner info in the JSON / XML
(`Destinatarios`)
- Fix refunding in PoS w.r.t. uninvoiced / invoiced combinations
of refunding and refunded order.
- We can invoice an uninvoiced order. Here we have to retrieve the
refunded Veri*Factu document from the order when creating the
record values for the refunding move.
- We can refund w/o invoice an invoiced order. Here We have to retrieve the
refunded Veri*Factu document from the invoice when creating the
record values for the refunding order.
- Move the error checks s.t. the record values can be extended
more easily.
- Invoices from PoS orders should not be simplified.
(The PoS order would be could enough.)
- We should not set the simplified partner automatically anymore
(in case no partner is set). That way there will be an error
when validating the order.
- We should use `sudo` when querying the number of spanish companies
in the database. The results should be independent of access rights.
task-None
Forward-Port-Of: odoo/odoo#221000