Thursday, April 2, 2026
5 changes · 18.0
Enhancements to existing features
This update enhances the accuracy of product imports by making product name searches case-insensitive and utilizing a similarity ratio (90%) to reduce incorrect matches. This ensures that products are correctly linked from customer databases, streamlining the import process and improving data reliability.
Original PR description
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match…
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`. - Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with `Wireless bluetooth speaker battery`), leading to unrelated matches. After this commit: - Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`. - Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names. Technical: - Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive. - Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match. - Added system parameter for configurable product name similarity threshold. task-5951469 Forward-Port-Of: odoo/odoo#252147
Resolved issues and error corrections
This update optimizes the PDF generation process for Odoo's SA (Saudi Arabia) edition, addressing a significant performance bottleneck. Previously, PDF creation was delaying checkout by a substantial amount of time. Now, PDFs are only generated on demand, aligning with ZATCA requirements and improving the cashier experience.
Original PR description
For SA companies, wkhtmltopdf PDF generation was accounting for ~47% of the sync_from_ui response time (~3.1s out of ~6.5s total), blocking the cashier at every order. The PDF is not needed during checkout: ZATCA requires only the signed XML and returns the QR code. The PDF can be generated on demand when the invoice is first viewed or downloaded. opw-6019994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects several issues in the generation of FA3 e-invoice XML files for Poland, specifically related to tax codes and currency conversions. The fix ensures accurate tax calculations and proper currency representation in the invoices, improving compliance with KSeF regulations. This impacts invoice accuracy and potential compliance risks.
Original PR description
**PROBLEM** 1. 5% ta have the wrong code `zw` (tax exempted), it should be `5` (small typo in code). 2. P_15 should be stated in the invoice currency, and not always in PLN (company currency). 3. KursWalutyZ is not right, it's the PLN->XXX rate (meaning we need to do PLN amount * PLN->XXX rate to get XXX amount, where XXX is the invoice currency) but it should be the XXX->PLN rate. **STEP TO REPRODUCE** 1. install l10n_pl_edi 2. Install the test certificate to send e-invoice (more info about how to do that in the chatter of the bug ticket). 3. Create an invoice with a line with a 5% tax, and in another currency than PLN with a custom currency rate. 4. Send the e-invoice using KSeF. 5. Open the xml attached in the chatter, and notice it has the problems listed above. Ticket [link](https://www.odoo.com/odoo/project.task/6075221) opw-6075221
This update corrects a reporting issue where employee leave balances incorrectly displayed duplicate entries after a department change. The fix ensures that leave balances always reflect the employee's current department, resolving inaccurate reporting and improving data accuracy. This change impacts the employee leave report functionality.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting >…
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting > Balance and apply the filter Department > Employee. 4. Change the employee’s department. 5. Create an allocation for the same employee and approve. 6. Apply the Department > Employee filter again. Observed behaviour: ---------------------------- After a department change: * Existing allocations keep the old department * New allocations use the new department As a result, duplicate employee entries appear in the report Cause: ---------- It is using [allocation.department_id.](https://github.com/odoo/odoo/blob/4c91eb3b2469cd04718005162b4572e9e3d07e72/addons/hr_holidays/report/hr_leave_employee_type_report.py#L62) Allocations store the department at creation time, which may differ from the employee’s current department, causing an incorrect report filtering. Solution: ------------ Fetch department_id from hr_employee instead of hr_leave_allocation in the hr_leave_employee_type_report and hr_leave_report. This ensures: * Leave balances always follow the employee’s current department * Correct aggregation when grouping by Department → Employee **NOTE:** Before this [commit](https://github.com/odoo-dev/odoo/commit/976e0f9a667f4573e73e33737425d370ec1e1452), the issue was resolved starting from version saas-18.4, as the balances were filtered using the employee's department (via `hr_version`). https://github.com/odoo/odoo/blob/104a33f093ca583c91db9705f087c73d8464c173/addons/hr_holidays/report/hr_leave_employee_type_report.py#L65-L74 related commit: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759 Since `hr_version` is no longer used in the query, this issue needs to be addressed again and forward-ported to all versions up to master. Before: <img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" /> After: <img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" /> opw-5220577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users attempted to split AES-encrypted PDF files within the Documents module. The fix involves adding error handling to gracefully manage missing dependencies, ensuring the Documents module functions reliably when processing PDFs. This prevents disruptions for users relying on this core functionality.
Original PR description
Currently, an error occurs when splitting an AES-encrypted PDF file in the Documents module if the `PyCryptodome` dependency is not installed. **Steps to Reproduce:** 1. Install Documents module. 2. Upload the sample PDFs in Documents. 3. Split the PDF. Sample File: https://drive.google.com/file/d/1OLl863YZ-QZtzdTpItsDgS7J4y6gsZx5/view?usp=drive_link **Error:** `DependencyError - PyCryptodome is required for AES algorithm` This commit wraps the `OdooPdfFileReader` inside a try-except block to handle any exceptions raised during PDF reading. Ref: https://github.com/odoo/odoo/blob/d2966d5f3624a64bf9740126b2854628b204d2a9/addons/account/models/ir_attachment.py#L56-L62 sentry-7272118595