Daily updates from Odoo
Navigate
Branch
Saturday, October 11, 2025
23 changes
8 changes
Resolved issues and error corrections
This fix prevents duplicate extra discount lines from appearing when multiple global discounts are applied to a sales order. It keeps order and tax calculations cleaner and avoids confusing totals for sales users and customers.
Original PR description
Because of the grouping on the computation_key in the taxes engine, when a second global discount was applied on a SO, it was creating two additional lines instead of one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230494
Reports now correctly show one-to-many field values instead of leaving them improperly formatted or missing. This improves report accuracy for users who rely on related line-item information in generated 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
Batch invoice sending now keeps Peppol only on invoices that are actually eligible for it. This prevents invoices meant to be sent by email, such as non-Peppol partners, from failing because Peppol was incorrectly applied.
Original PR description
…ng methods When sending invoices in batch with multiple sending methods (for example 1 by Peppol, 2 by Email), Peppol was wrongly set on invoices where it didn't make sense. Steps to reproduce: 1. Go into a Peppol compatiable company (Eg: Belgium) 2. Go into settings, enable Peppol. 3. Create & post two invoices: one to an US partner, the other one to a Peppol partner (For example a belgian partner with a vat set.). Make sure to set the email on both. 4. Send them in batch: the wizard says 1 by Peppol, 2 by Email, which is correct. 5. If you send them, the one to the US partner that is not supposed to go through Peppol will end up in error, with the email not sent either. Root cause: We are doing some Peppol checks before checking if it actually make sense to apply this sending method on the move. task-none (reported from our production) Forward-Port-Of: odoo/odoo#230880
Indian e-invoice submissions now calculate invoice values correctly when a global discount is applied. This prevents government EDI validation errors that could block affected invoices from being 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
Spanish Veri*Factu invoices for customers outside Spain now receive the correct export regime key instead of being marked as general regime operations. This helps businesses produce more accurate tax reporting data and avoid manual correction for export invoices.
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 fixes an issue where creating a new journal entry with the same accounting date as the previous entry could fail to refresh required information. Users should now see the expected draft title and be able to save records without them remaining incorrectly marked as unsaved.
Original PR description
Steps to reproduce ================== - Install accounting - Go to Accounting > Accounting > Journal Entries - Create a new record - Select an Accounting Date in the previous month - An onchange is called and the title is changed to draft - Save the record - Click on New - Select the same date - The onchange isn't triggered - Save the record - The record stays dirty and the title is missing Cause of the issue ================== https://github.com/odoo/odoo/commit/44f69ae726b1ff8876c38e858c64fed0f5b1a766 lastAppliedStringValue should be reset inside computeBasePickerProps Solution ======== We backport the code from 19.0 where this was fixed opw-5145113 Forward-Port-Of: odoo/odoo#230774
This fixes a small issue that could stop users from creating a new analytic distribution model when expected text data was missing. The change adds a safeguard so the process continues normally without affecting other analytic features.
Original PR description
Current behavior before PR: When trying to create a new analytic distribution model might fail because string might not be defined and substr() could fail. <img width="1139" height="435" alt="odoo" src="https://github.com/user-attachments/assets/2be5a35c-600e-4484-af72-91f778681bcf" /> Desired behavior after PR is merged: We could check if there is string before de substr method. That would solve the problem and will not affect anywhere else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230481
This fixes French leave reporting when an employee's working hours differ from the company's default schedule. Time off entries now use the employee's actual schedule, helping payroll and timesheet records show the correct leave duration.
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
5 changes
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 fixes an issue that could prevent users from creating a new analytic distribution model when an expected text value was missing. The change adds a safeguard so the setup process continues reliably without affecting other behavior.
Original PR description
Current behavior before PR: When trying to create a new analytic distribution model might fail because string might not be defined and substr() could fail. <img width="1139" height="435" alt="odoo" src="https://github.com/user-attachments/assets/2be5a35c-600e-4484-af72-91f778681bcf" /> Desired behavior after PR is merged: We could check if there is string before de substr method. That would solve the problem and will not affect anywhere else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230481
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
1 change
Resolved issues and error corrections
Invoices now point users to the active, reconciled payment instead of an older draft copy when payments are reset, duplicated, and reconciled. This prevents confusion when reviewing invoice payment status and helps users access the correct payment record from the invoice.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/enterprise#89089
2 changes
Enhancements to existing features
Updating customer details linked to many helpdesk tickets is now more reliable. The change prevents large ticket descriptions from being unnecessarily loaded during recalculation, reducing the risk of memory errors for high-volume support teams.
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
SEPA Direct Debit payments now correctly validate whether a mandate is still active before using it for token payments. This prevents valid future-expiring mandates from being rejected and helps avoid unnecessary payment failures.
Original PR description
The check to ensure that the mandate used in a token payment is still valid had two issues: - It was comparing a date (the mandate's end date) with a datetime. - It was incorrectly rejecting mandates expiring in the future, while it should have done the opposite. Forward-Port-Of: odoo/enterprise#96518 Forward-Port-Of: odoo/enterprise#96143
6 changes
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
1 change
Resolved issues and error corrections
Creating a new analytic distribution model is made more reliable by preventing an error when expected text is missing. This avoids a small but disruptive failure in analytic setup without changing normal behavior.
Original PR description
Current behavior before PR: When trying to create a new analytic distribution model might fail because string might not be defined and substr() could fail. <img width="1139" height="435" alt="odoo" src="https://github.com/user-attachments/assets/2be5a35c-600e-4484-af72-91f778681bcf" /> Desired behavior after PR is merged: We could check if there is string before de substr method. That would solve the problem and will not affect anywhere else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230481