Daily updates from Odoo
Thursday, June 18, 2026
8 changes · 17.0
Enhancements to existing features
This update enhances the error messages displayed when leave validity conflicts occur, particularly when creating public holidays. This change improves the user experience for both customers and our support team by providing clearer troubleshooting guidance and reducing the need for manual debugging.
Original PR description
The current message is pretty useless as of now when a lot of leaves are being written to, notably when creating a public holiday, which sets the state of all the leaves overlapping the public holiday's day to be reevaluated, and if an error occurs, you have to go through every employee's leave allocation and leaves taken to hopefully find one who might have to many days taken/not enough allocated. This extra information will be a huge QOL improvement, for the customer who will be able to troubleshoot his issue himself more easily, but also for our support team as the only way to debug those kind of issues now is to put a breakpoint there and see what employee has an issue. opw-4411999
Resolved issues and error corrections
This update resolves an issue where payslips weren't correctly generated for employees registered within branch companies of a larger organization. The fix ensures that all employees within the company hierarchy, including those in branch offices, are accurately included in payslip calculations. This improves payroll accuracy and reporting.
Original PR description
Bug: employees registered on branch companies don't appear in the
employee_id field when creating a payslip from the parent company.
Reason: the domain used ('company_id', '=', company_id) which only
matches the exact company, not its children.
Solution: replaced '=' with 'child_of' to include all descendant
companies in the hierarchy.
task - 6299634This update resolves an issue where payslips weren't generated correctly for employees registered within branch companies of a larger organization. The fix ensures that all employees within the company hierarchy are included when creating payslips, improving payroll accuracy and reporting. This change impacts the HR Payroll module.
Original PR description
Bug: employees registered on branch companies don't appear in the
employee_id field when creating a payslip from the parent company.
Reason: the domain used ('company_id', '=', company_id) which only
matches the exact company, not its children.
Solution: replaced '=' with 'child_of' to include all descendant
companies in the hierarchy.
task - 6299634This update fixes an issue where emojis, particularly complex ones like `👨🚒`, were being displayed incorrectly due to how they were encoded. The team backported a more robust regex pattern from a recent version of Odoo to ensure all emojis are correctly rendered. This improves the overall email experience for users.
Original PR description
Bug === Some emoji like `👨🚒` are separated, because they are built using `👨 + Emoji_Modifier + 🚒` (`\uFE0F` can also be used to get the variant of the emoji). Adapt the regex to take into account those Unicode variations. Task-5491124
This update fixes an issue where work order durations were inaccurately calculated due to overlapping time entries. By filtering and merging productive and performance time, the system now provides a more precise duration, aligning with cost valuation needs. Additionally, a fix ensures accurate timestamp handling to prevent duration discrepancies.
Original PR description
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current…
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current Situation: Currently real duration is total duration of each time tracking which is not consistent with the time that use to calculate the cost for valuation , see https://github.com/odoo/odoo/pull/205154 .The real duration of a work order was incorrectly summing all time tracking entries regardless of their loss type, and using simple addition which double-counts overlapping intervals. * Solution: - Filter time entries to only 'productive' and 'performance' loss types, excluding 'availability' and 'quality' as they represent downtime/blocking time, not actual work duration. - Pool all productive and performance entries into a single Intervals call so that overlaps across both types are merged in one pass. Note: the enterprise17 implementation groups time entries by loss_type into separate buckets before calling Intervals, which means overlaps between 'productive' and 'performance' entries are not merged and get double-counted. Pooling both types together before the Intervals call avoids this. * This also fix: - Fix _set_duration to ensure newly created time entries start after the latest existing entry's end date. Without this, calling _set_duration twice in quick succession (e.g. in tests) produces two entries with overlapping timestamps, which Intervals correctly merges into one, causing the computed duration to be half the expected value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue impacting the processing of invoices with multiple related documents, particularly in cancellation scenarios. By switching to a specialized index, the system now handles a larger volume of data efficiently, preventing performance bottlenecks. This ensures smoother invoice processing and avoids potential delays.
Original PR description
The field `l10n_mx_edi_cfdi_origin` can contain a large number of associated UUIDs, especially in complex cancellation scenarios. The default B-tree index fails when this field exceeds 2704 bytes, which occurs after approximately 20 UUIDs. By switching to a trigram index, we avoid the entry size limit of PostgreSQL's B-tree nodes. This ensures that invoices with many related documents can be processed while maintaining efficient search performance for partial matches on this field. **Video before the fix:** https://youtu.be/24u0HbxwIH8 **Video after the fix:** https://youtu.be/sUelv1HZMvI
This update resolves an issue where rapid changes to product quantities in the product catalog could lead to incorrect final quantities on Sale Order Lines. The fix ensures that quantity updates are processed sequentially, preventing data inconsistencies. This improves the reliability of sales order calculations.
Original PR description
Fix a concurrency race condition in the product catalog where rapid quantity updates could result in incorrect final quantities on Sale Order Lines (SOL). Steps to produce: --- - We need a DB with…
Fix a concurrency race condition in the product catalog where rapid quantity updates could result in incorrect final quantities on Sale Order Lines (SOL). Steps to produce: --- - We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot. - Open a Sale Order (SO) and open the Product Catalog. - Rapidly change or paste quantities (e.g., changing from 1 to 100) across multiple records very fast. - Return to the SO. Some lines intermittently retain an intermediate quantity (e.g., qty = 1) instead of the final entered value. Cause: --- - This is a concurrency issue. In the faulty cases, the `update_order_line_info` setting quantity to 1 takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1. Fix: --- - We can chain RPC calls to ensure that each request is completed before starting the next one. Backport of ef9554ad95d5e39ab7b550db0d39454373f99aed opw-6282877 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request formally signs David Sonnet's Individual Contributor License Agreement for Odoo. This ensures compliance with Odoo's licensing terms and allows David to contribute to the project. The addition of the `dsonnet.md` document provides the necessary legal documentation.
Original PR description
Signing the Odoo Individual Contributor License Agreement v1.0. Adds `doc/cla/individual/dsonnet.md`. --- I confirm I have read the PR guidelines at www.odoo.com/submit-pr