Saturday, October 11, 2025
4 changes · saas-18.3
Enhancements to existing features
Updating customer details like phone, email, or name no longer causes Helpdesk to load large ticket descriptions unnecessarily. This reduces the risk of memory errors for customers with many tickets and makes partner updates more reliable.
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
Invoices in the Indian EDI flow that include a global discount are now reported with correct taxable and total values. This prevents government submission errors and helps discounted invoices be processed 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
Spanish Veri*Factu invoices for customers outside Spain now suggest the correct export regime key instead of defaulting to the general regime. This helps businesses submit more accurate electronic invoice data and avoid manual corrections for export transactions.
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
This fix ensures time off hours in the French localization are calculated using the employee's own working schedule, even when it starts earlier or ends later than the company schedule. This prevents incorrect timesheet and work entry durations for employees whose schedules differ from the default company hours.
Original PR description
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule.…
This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry (`account.analytic.line`) creation, and the duration field is created using the company schedule. The reason is the case which the employee schedule starts before company scheudle or ends after it. To reproduce the bug: 1- Make a db with fr company (install l10n_fr) 2- Make two working schedule: - Company schedule with working day on Monday from 8:00-12:00 13:00-17:00 - Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15 3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee 4- Allocate some time off to the employee and take a time off on Monday 5- Check the work entries for the day you took the day off on timesheet app 6- 7:24 `Worked Hour` is shown instead of 7:40 The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered. opw-4868643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230621 Forward-Port-Of: odoo/odoo#222262