Daily updates from Odoo
Friday, August 15, 2025
17 changes
5 changes
Resolved issues and error corrections
This fix makes an internal bus testing helper more reliable by preventing a timing issue that could cause automated tests to fail unexpectedly. It also corrects how test errors are reported, helping teams identify real problems more clearly and keeping release validation stable.
Original PR description
This change addresses two issues in the `waitForChannels` test utility: - Fixes a race condition. The `failTimeout` variable was sometimes accessed before its `setTimeout` declaration had been executed. This happens when a fast bus event triggers the `onWebsocketEvent` handler, resulting in a reference error. The variable is now declared at the beginning of the function, making it available before any access (fixes runbot-223252). - Corrects error in def.reject. `message` only takes one param, and a string does not have a join method. Forward-Port-Of: odoo/odoo#222967
This fix prevents Odoo Accounting from creating extra, unlinked exchange difference entries when an invoice and payment in the same foreign currency differ slightly due to rounding. It improves reconciliation accuracy and helps keep accounting records cleaner in affected multi-currency cases.
Original PR description
After https://github.com/odoo/odoo/pull/204746, in some situations we will default the amount of the partial on residual of debit aml even if this one is larger than the credit aml amount. This lead to multiple exchange moves creation that are not properly linked to the reconciliation chain. Steps to reproduce: 1/ Setup foreign currency with rate 0.648587 (ex 0.648587 USD = 1 AUD for AUD company) 2/ Create invoice with lines 36 USD (55.51 AUD) -7.2 USD (-11.1 AUD) => Receivable will be 28.8 USD (44.41 AUD) because it's computed from sum of above lines 3/ Register a payment of 28.8 USD (44.4 AUD) => Two exchange moves will be created with 0.01 in credit, none of them is in a partial with the invoice or payment line This PR makes sure that we take the smallest amount of residual if both credit and debit are considered as fully matched. opw-4835254 Forward-Port-Of: odoo/odoo#219237
French tax reports now compare calculated totals with proper rounding, avoiding false mismatches caused by hidden decimal precision. This helps prevent incorrect warnings or validation issues when displayed amounts are effectively the same.
Original PR description
Currently, the code was checking for a strict equality between two sums. However, it may happen that there are many decimals that aren't displayed on the UI, hence the strict equality check fails. For instance `30201.63 != 30201.629999999997`. Instead, we now use the `float_compare` which takes care of rounding issues. opw-5000147 Forward-Port-Of: odoo/enterprise#92405 Forward-Port-Of: odoo/enterprise#92356
Colombian DIAN invoice and credit note email templates will no longer disappear when the module is upgraded. This preserves users' sending workflows and avoids having to recreate or recover these templates after updates.
Original PR description
**Steps to reproduce:** - Install l10n_co_dian => "Invoice (DIAN): Sending" and "Credit Note (DIAN): Sending" email templates are created - Upgrade l10n_co_dian **Issue:** "Invoice (DIAN): Sending" and "Credit Note (DIAN): Sending" are deleted. **Cause:** Email templates are reset during a module upgrade. These DIAN email templates are not defined in a XML, but created by a python function. This function is only called during installation. **Solution:** Set the "nopupdate" to True for these email templates to prevent them to be reset during the module upgrade. opw-4964347 Forward-Port-Of: odoo/enterprise#91008
Subscription invoices for timesheet-based services now exclude entries dated on the next invoice date when no timesheet period is specified. This prevents hours from being attached to the wrong invoice and ensures they remain available for the following billing period.
Original PR description
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next…
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next invoice date of the subscription. This occurs if the client does not specify a timesheet period when creating the invoice. For example, the user invoices a subscription for the period of July 1st to July 31st and the next invoice date of the subscription is August 1st. There are timesheets dated in July and a timesheet dated August 1st. The quantity delivered for the invoice will only include timesheets within the July period. However, the linked timesheet to the invoice will mistakenly include the timesheet from August 1st. Purpose: Although the linked timesheet has no effect on the computation of qty_delivered for the current period, the timesheets dated the same as the next_invoice_date will get linked to the invoice and no longer be considered as delivered hours for the next period, which could cause gaps in hours delivered. The next_invoice_date should not be included in the date range when linking timesheets within the period of the invoice, since these hours were not included in the computation of quantity delivered. Steps to reproduce on Runbot: 1. Install Sales, Project, Timesheet 2. Enable Timesheet in Project > Settings 3. Create a service product that is based on timesheet and creates project and task on order 4. Create a quotation for the service product and set the recurrence to be monthly and set the start date to be the first of the past month 5. Confirm the quotation and set the next invoice date to be the first of the current month 6. Create timesheet hours within the period and one dated to be the first of the current month 7. Create an invoice for the subscription and notice that the timesheet from the first of the current month is linked to the invoice. opw-4689894 Forward-Port-Of: odoo/enterprise#92368 Forward-Port-Of: odoo/enterprise#92250
6 changes
Resolved issues and error corrections
This fix ensures foreign-currency invoice and payment reconciliations use the smaller matching residual amount when both sides are considered fully matched. It prevents extra exchange difference entries from being created without proper reconciliation links, improving accounting accuracy in affected edge cases.
Original PR description
After https://github.com/odoo/odoo/pull/204746, in some situations we will default the amount of the partial on residual of debit aml even if this one is larger than the credit aml amount. This lead to multiple exchange moves creation that are not properly linked to the reconciliation chain. Steps to reproduce: 1/ Setup foreign currency with rate 0.648587 (ex 0.648587 USD = 1 AUD for AUD company) 2/ Create invoice with lines 36 USD (55.51 AUD) -7.2 USD (-11.1 AUD) => Receivable will be 28.8 USD (44.41 AUD) because it's computed from sum of above lines 3/ Register a payment of 28.8 USD (44.4 AUD) => Two exchange moves will be created with 0.01 in credit, none of them is in a partial with the invoice or payment line This PR makes sure that we take the smallest amount of residual if both credit and debit are considered as fully matched. opw-4835254 Forward-Port-Of: odoo/odoo#219237
This fix makes an internal bus testing helper more reliable by preventing timing-related failures when events arrive very quickly. It also corrects how errors are reported in the helper, reducing false test failures and improving development stability.
Original PR description
This change addresses two issues in the `waitForChannels` test utility: - Fixes a race condition. The `failTimeout` variable was sometimes accessed before its `setTimeout` declaration had been executed. This happens when a fast bus event triggers the `onWebsocketEvent` handler, resulting in a reference error. The variable is now declared at the beginning of the function, making it available before any access (fixes runbot-223252). - Corrects error in def.reject. `message` only takes one param, and a string does not have a join method. Forward-Port-Of: odoo/odoo#222967
This update reverses a recent accounting tax rounding change. It helps restore the previous behavior for tax total calculations, reducing the risk of unexpected invoice or tax amount differences.
Original PR description
As per https://github.com/odoo/odoo/pull/222759#issuecomment-3188749767 --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223053
This fix prevents the Colombian DIAN invoice and credit note email templates from being removed when the module is upgraded. Businesses using Colombian electronic invoicing keep their configured sending templates intact, avoiding disruption after updates.
Original PR description
**Steps to reproduce:** - Install l10n_co_dian => "Invoice (DIAN): Sending" and "Credit Note (DIAN): Sending" email templates are created - Upgrade l10n_co_dian **Issue:** "Invoice (DIAN): Sending" and "Credit Note (DIAN): Sending" are deleted. **Cause:** Email templates are reset during a module upgrade. These DIAN email templates are not defined in a XML, but created by a python function. This function is only called during installation. **Solution:** Set the "nopupdate" to True for these email templates to prevent them to be reset during the module upgrade. opw-4964347 Forward-Port-Of: odoo/enterprise#91008
Users can once again access Export and Insert in spreadsheet from the action menu when selecting documents in kanban or list views. The actions remain hidden only while previewing a document, preventing confusion without removing expected bulk actions.
Original PR description
Issue: When clicking on the action dropdown in the kanban and list view, the actions 'Export' and 'Insert in spreadsheet' did not appear anymore. Cause: This was the result of a previous fix that aimed to hide those actions when a user is in the preview of a document. This fix unintentionally also removed them when a user is selecting documents in the kanban and list view. Solution: Adapt the initial omit fix to only hide the actions when a document is in preview. Task-4898152 Forward-Port-Of: odoo/enterprise#91926
Subscription invoices now link only the timesheet entries that belong to the invoiced period, excluding entries dated on the next invoice date. This prevents hours from being attached to the wrong invoice and ensures they remain available for billing in the following period.
Original PR description
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next…
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next invoice date of the subscription. This occurs if the client does not specify a timesheet period when creating the invoice. For example, the user invoices a subscription for the period of July 1st to July 31st and the next invoice date of the subscription is August 1st. There are timesheets dated in July and a timesheet dated August 1st. The quantity delivered for the invoice will only include timesheets within the July period. However, the linked timesheet to the invoice will mistakenly include the timesheet from August 1st. Purpose: Although the linked timesheet has no effect on the computation of qty_delivered for the current period, the timesheets dated the same as the next_invoice_date will get linked to the invoice and no longer be considered as delivered hours for the next period, which could cause gaps in hours delivered. The next_invoice_date should not be included in the date range when linking timesheets within the period of the invoice, since these hours were not included in the computation of quantity delivered. Steps to reproduce on Runbot: 1. Install Sales, Project, Timesheet 2. Enable Timesheet in Project > Settings 3. Create a service product that is based on timesheet and creates project and task on order 4. Create a quotation for the service product and set the recurrence to be monthly and set the start date to be the first of the past month 5. Confirm the quotation and set the next invoice date to be the first of the current month 6. Create timesheet hours within the period and one dated to be the first of the current month 7. Create an invoice for the subscription and notice that the timesheet from the first of the current month is linked to the invoice. opw-4689894 Forward-Port-Of: odoo/enterprise#92368 Forward-Port-Of: odoo/enterprise#92250
2 changes
Resolved issues and error corrections
Tax reports for France and Belgium now compare totals in a way that accounts for normal rounding differences. This prevents false mismatches when displayed amounts are effectively the same, improving reliability for users reviewing reports.
Original PR description
Currently, the code was checking for a strict equality between two sums. However, it may happen that there are many decimals that aren't displayed on the UI, hence the strict equality check fails. For instance `30201.63 != 30201.629999999997`. Instead, we now use the `float_compare` which takes care of rounding issues. opw-5000147 Forward-Port-Of: odoo/enterprise#92405 Forward-Port-Of: odoo/enterprise#92356
Subscription invoices for timesheet-based services now link only the hours that belong before the next invoice date. This prevents hours from the next billing period from being incorrectly attached to the current invoice, helping avoid missing billable time in future periods.
Original PR description
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next…
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next invoice date of the subscription. This occurs if the client does not specify a timesheet period when creating the invoice. For example, the user invoices a subscription for the period of July 1st to July 31st and the next invoice date of the subscription is August 1st. There are timesheets dated in July and a timesheet dated August 1st. The quantity delivered for the invoice will only include timesheets within the July period. However, the linked timesheet to the invoice will mistakenly include the timesheet from August 1st. Purpose: Although the linked timesheet has no effect on the computation of qty_delivered for the current period, the timesheets dated the same as the next_invoice_date will get linked to the invoice and no longer be considered as delivered hours for the next period, which could cause gaps in hours delivered. The next_invoice_date should not be included in the date range when linking timesheets within the period of the invoice, since these hours were not included in the computation of quantity delivered. Steps to reproduce on Runbot: 1. Install Sales, Project, Timesheet 2. Enable Timesheet in Project > Settings 3. Create a service product that is based on timesheet and creates project and task on order 4. Create a quotation for the service product and set the recurrence to be monthly and set the start date to be the first of the past month 5. Confirm the quotation and set the next invoice date to be the first of the current month 6. Create timesheet hours within the period and one dated to be the first of the current month 7. Create an invoice for the subscription and notice that the timesheet from the first of the current month is linked to the invoice. opw-4689894 Forward-Port-Of: odoo/enterprise#92368 Forward-Port-Of: odoo/enterprise#92250
4 changes
Resolved issues and error corrections
This update fixes several issues affecting e-invoicing validation, quality control stock handling, loyalty pricelist behavior, recruitment search, and accounting performance. Businesses should see more reliable invoice compliance, smoother operational workflows, and faster reconciliation in large accounting databases.
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
This fix makes point-of-sale loyalty tests more reliable by ensuring the test customer appears near the top of the customer list. It helps prevent random test failures that can block automated validation, without changing customer-facing functionality.
Original PR description
Tours in POS rely on clicking on partners. But the POS interface does not load ALL records, meaning that depending on the test environment, the tested partner "Test Partner 2" can be too far down the list and not loaded properly. This commit fixes this by adding "AAA" in front of the name to move it up un the list order. It's a temporary fix to unblock the runbot and will be investigated more in details. 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
This fixes an accounting issue where reconciling invoices and payments in the same foreign currency could create duplicate exchange adjustment entries that were not correctly linked. Businesses get cleaner reconciliation records and fewer incorrect small currency difference entries.
Original PR description
After https://github.com/odoo/odoo/pull/204746, in some situations we will default the amount of the partial on residual of debit aml even if this one is larger than the credit aml amount. This lead to multiple exchange moves creation that are not properly linked to the reconciliation chain. Steps to reproduce: 1/ Setup foreign currency with rate 0.648587 (ex 0.648587 USD = 1 AUD for AUD company) 2/ Create invoice with lines 36 USD (55.51 AUD) -7.2 USD (-11.1 AUD) => Receivable will be 28.8 USD (44.41 AUD) because it's computed from sum of above lines 3/ Register a payment of 28.8 USD (44.4 AUD) => Two exchange moves will be created with 0.01 in credit, none of them is in a partial with the invoice or payment line This PR makes sure that we take the smallest amount of residual if both credit and debit are considered as fully matched. opw-4835254 Forward-Port-Of: odoo/odoo#219237
This change reverses a recent accounting tax rounding adjustment. It helps restore the previous behavior for tax total calculations, reducing the risk of unexpected invoice or accounting totals.
Original PR description
As per https://github.com/odoo/odoo/pull/222759#issuecomment-3188749767 --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr