Daily updates from Odoo
Saturday, May 9, 2026
5 changes · saas-18.3
Resolved issues and error corrections
The budget report now accurately displays financial data without duplicate analytic lines. This issue stemmed from a recent performance optimization of the budget report query, which inadvertently introduced duplicate entries. The fix ensures unique and reliable reporting by restructuring the underlying queries.
Original PR description
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item…
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item (linked to Analytic Account A). - Open the budget report and remove the default "open budget" filter. Duplicate amounts appear in the pivot view and duplicate lines appear in the list view. #### Cause: In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report. #### Fix: Use three separate queries, each with specific filter conditions to guarantee unique results: Q1 - Analytic lines with no matching budget line. Q2 - Analytic lines matched to a budget line with no company (null-company). Q3 - Analytic lines matched to a company-specific budget line. OPW-6051696 Forward-Port-Of: odoo/enterprise#116612
This update fixes an error in how VAT reimbursement moves are calculated when carrying over unclaimed tax amounts. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures correct VAT reimbursement processing for June.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#115451
This update fixes an issue where abandoned cart emails were being sent twice. A recent change in how the system handles email templates caused a conflict with a previous fix. The update now correctly accounts for this change, ensuring abandoned cart emails are sent only once.
Original PR description
During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them. But…
During a previous fix (https://github.com/odoo/odoo/pull/206158), fallback values were added for an explicit `email_to` if the default email template for the abandonned cart was missing them. But since (https://github.com/odoo/odoo/pull/172714), the template uses `use_default_to` == True, which will compute the default partner and add them to `partner_ids` of the `mail.mail` record. So the old bug of "abandoned cart email is sent twice" reappered: the if condition fails to account for `use_default_to` being set, so the partner email is set explicitly on `email_to` AND referenced in `partner_ids`, which de-facto sends the email twice to the customer on the sales order. ## FIX: We account for `use_default_to` in the if condition before adding the fallback. How to reproduce: 1) Setup a database with demo data and website_sale 2) Visit the shop as a visitor, add stuff to your cart 3) Sign up for portal access and add new stuff to cart (will attribute SO to new portal account) 4) Wait for the abandoned cart email to trigger (can be forced by playing with `cart_recovery_email_sent`: false,`is_abandoned_cart`: true and triggering the CRON) -> mail is sent twice to the customer Remarks: - changed the unit test to actually capture the generated `mail.mail` and apply some asserts on it OPW-6134731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261039
This update fixes an issue where taxes were incorrectly assigned to the wrong company due to a change in how the system cached tax information. By partitioning the cache based on company ID, we ensure that taxes are now correctly associated with the appropriate business. This prevents financial errors and maintains data accuracy.
Original PR description
Details and steps to reproduce are in Issue #262709 Cause: In #248680 the cache was changed to be global (per cr), meaning it is shared across companies. We need to partition the cache by company_id to prevent the assignment of taxes from the wrong company. OPW-6189579 Forward-Port-Of: odoo/odoo#262779
This update corrects a visual issue in the Project Gantt view where flexible employees were incorrectly marked as unavailable during weekends and off-hours. The fix ensures that flexible employees only appear unavailable when they have approved leaves or public holidays, improving the accuracy of project timelines.
Original PR description
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out…
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out Current Behavior --- Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view. Expected Behavior --- Flex employees should have no grayed-out days except approved leaves and public holidays. Issue --- When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered. Fix --- Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`. Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 task - 5063071 Forward-Port-Of: odoo/enterprise#113247