Daily updates from Odoo
Saturday, October 11, 2025
6 changes · 19.0
New functionality added to Odoo
This pull request introduces a new Estate module with basic property records, menus, list views, and form views. It also includes changes in Sales order screens, which may support early integration or workflow adjustments for property-related sales.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Updating customer contact details now avoids loading large helpdesk ticket descriptions unnecessarily. This reduces the risk of memory errors for customers with many tickets while keeping ticket information up to date.
Original PR description
Issue: When updating partner fields such as `email`, `name` and `phone` on the partner records, the ticket fields are recomputed. During the recomputation, the `description` field is loaded into…
Issue: When updating partner fields such as `email`, `name` and `phone` on the partner records, the ticket fields are recomputed. During the recomputation, the `description` field is loaded into memory and with many helpdesk tickets, this will cause a memory error. Purpose of this PR: To explicity fetch `partner_id` before computing partner fields on the helpdesk ticket. Example: With a partner record with 25,000 helpdesk tickets each with a description of varying text and images, we hit the memory limit when trying to update the partner phone. With these changes, peak memory usage reached 271.4 MB. Notes: Originally wanted to avoid changing the field definition however this would require adding `with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model.`with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model. Memgraph and Stats before changes <img width="1912" height="862" alt="memgraph_b4_changes" src="https://github.com/user-attachments/assets/f5e95a42-83c8-4250-bdf3-440740a9fb33" /> <img width="640" height="352" alt="stats_b4_changes" src="https://github.com/user-attachments/assets/a82ccd69-1359-4ba8-81a0-52aeace762db" /> opw-5069424 Forward-Port-Of: odoo/enterprise#96198
Resolved issues and error corrections
Indian electronic invoices with a global discount were being rejected because discount lines were not reflected correctly in the submitted totals. This fix aligns the invoice values in the EDI payload so discounted invoices can be submitted successfully.
Original PR description
Submitting an EDI for an invoice containing a global discount line (negative amount line without tax) raised the following errors: 1. 2182 – Taxable value of all items must be equal to total taxable value 2. 2189 – Invalid total Invoice Value This occurred due to the `account_tax` refactor in version 18.0, where lines without taxes are no longer included in `_aggregate_base_line_tax_details`. As a result, the `global_discount_line` in `l10n_in_edi` was excluded from the base_amount computation. This fix adjusts the following JSON fields: - `AssVal` → Previously added global_discount_amount to restore the base. Now remains directly aligned with base_amount. - `TotInvVal` → Previously skipped discount deduction. Now explicitly deducts the discount. **task**-5158762 Forward-Port-Of: odoo/odoo#230962
The point of sale system now saves large offline data batches one after another instead of all at once. This reduces the risk of slowdowns or failed saves when handling high volumes of data, improving stability for busy stores.
Original PR description
When saving large datasets to IndexedDB, all batches were started in parallel. This could cause excessive open transactions, long execution times, and premature transaction aborts due to the timeout. With this commit, batches are now processed one at a time, ensuring that each batch completes before starting the next. This improves stability and prevents transaction overload when handling high volumes of data. opw-5052956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230380 Forward-Port-Of: odoo/odoo#226129
Reports now correctly show information from one-to-many fields, matching how other relationship fields are already handled. This prevents missing or poorly formatted data in generated business documents.
Original PR description
For now, `One2Many` fields are not displayed correctly in reports. This is because for other types of fields (`ManyToMany`, `ManyToOne`, etc.), there are Converter classes (`ManyToManyConverter`) `ir.qweb.field.many2many` that implement `value_to_html`. However, for `OneToMany` fields, no implementation is present. This commit adds a `OneToManyConverter`, which is essentially the same as the `ManyToMany `one. opw-5098466 Forward-Port-Of: odoo/odoo#231057 Forward-Port-Of: odoo/odoo#229289
Spanish Veri*Factu invoices now select the export regime when taxes indicate an export or equivalent exempt operation. This prevents affected invoices for customers outside Spain from being classified under the general regime, improving compliance accuracy.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice for a partner outside Spain (or with the tax "0% EX G") - Check the "Veri*Factu Regime Key" under the page "Veri*Factu" - It should be "Export" (02) but it's "General Regime Operation" (01) ### Cause: `_l10n_es_edi_verifactu_get_suggested_clave_regimen()` is called on the tax "0% EX G". The line ```taxes.filtered(lambda tax: (tax.l10n_es_type not in main_tax_types or tax._l10n_es_edi_verifactu_get_applicability() != forced_tax_applicability))``` doesn't do what the comment says: remove the main taxes with a different applicability. ### Solution: Change the `!=` to `==` so that the line does the same thing as the comment. opw-5071665 Forward-Port-Of: odoo/odoo#230823