Daily updates from Odoo
Thursday, April 2, 2026
15 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 ensures that archived channels and threads disappear instantly from the Discuss view, eliminating the need for page refreshes. Additionally, archiving a channel now automatically hides its subchannels. This improves the user experience and simplifies channel management.
Original PR description
Current behavior before PR: - Archived channels and threads remain visible in Discuss until the page is refreshed. - Archiving a channel does not affect its subchannels. Desired behavior after PR is merged: - Archived channels and threads are instantly removed from the Discuss view without requiring a page refresh. - Archiving a channel also archives and hides its subchannels. task-id: [4764934](https://www.odoo.com/odoo/project/1519/tasks/4764934) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that archived channels and their threads are instantly removed from the Discuss view, eliminating the need for page refreshes. Previously, archived content remained visible. Now, archiving a channel also automatically hides its subchannels, providing a cleaner and more organized experience.
Original PR description
Current behavior before PR: - Archived channels and threads remain visible in Discuss until the page is refreshed. - Archiving a channel does not affect its subchannels. Desired behavior after PR is merged: - Archived channels and threads are instantly removed from the Discuss view without requiring a page refresh. - Archiving a channel also archives and hides its subchannels. task-id: 4764934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue where archived email templates were showing up in the applicant refusal workflow. The fix ensures that archived templates are no longer automatically included when searching for email templates during the refusal process, improving the user experience. This was caused by a technical issue related to how the system handles context keys.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.
Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template" and click on 'Search More'
7. Observe available templates
Issue:
-------
1. Archived email templates are displayed in the Email Template field.
2. If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template
Cause:
----------
1. After the [refactoring of Many2oneField](https://github.com/odoo-dev/odoo/commit/3670f78be767396f322ff3ebf068af5c2f547b36) to use dynamicInfo.context,
now ensures that global context keys propagate to relational fields.
The archive_applicant method opens the refuse wizard with **'active_test': False**
in the context to allow refusing archived applicants. As a result, this context is now
applied when fetching the email templates, causing archived records to be included in
the search results.
https://github.com/odoo/odoo/blob/7966fae0c1fd7cfb6023efc0c274b8b395bf862f/addons/web/static/src/views/fields/relational_utils.js#L313-L321
2. Moreover, the `_compute_send_mail` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L29-L33
Solution:
-----------
- Pass `context="{'active_test': True}"` to the `template_id` field to ensure
archived templates are excluded by default, while still allowing users
to manually search for them if needed.
- Update `_compute_send_mail` to ensure only active templates are
automatically assigned.
**NOTE:**
Issue 1 only exists till saas-18.4. From saas-18.4, email templates are fetched using [search_read](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/addons/mail/static/src/core/web/mail_composer_template_selector.js#L33-L46) without passing
the context. Additionally, [search_read removes 'active_test'](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/odoo/orm/models.py#L5780-L5785)
before formatting the result, so archived records are not included.
opw-5974244
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis 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 allows users to disable automatic PDF generation when importing XML invoices. Previously, Odoo always created a PDF, even if the invoice didn't include one. This change provides greater flexibility and control over invoice processing, aligning with user preferences.
Original PR description
Commit 7bc35c4 introduced automatic PDF generation for imported XML invoices that don't include an embedded PDF file. However, this behavior was mandatory and couldn't be disabled. This commit adds a new configuration parameter to allow users disable this behaviour. Task-6050566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where 'View Quotation' buttons in email notifications weren't consistently translated for recipients in different languages. The change dynamically adjusts the language context during email creation, ensuring accurate translation of all action buttons. This improves the user experience for international customers.
Original PR description
When sending a quotation or sales order via email to a follower, the action button in the notification (e.g., "View Quotation") was appearing partially translated in the recipient's language. The issue came from the document description being explicitly evaluated using the sender's language context usually English) during the email composition phase, so it could not be correctly re-translated by the mail engine when rendering the final layout for a recipient using a different language. This commit allows the language context to be dynamic when preparing the document description for the email composer, ensuring the action button is fully and accurately translated. --- opw-5976084
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 ensures that line grouping functionality within the account_edi_ubl_cii module is limited to invoices only. Previously, grouping was possible for other document types like journal entries, which could cause errors. This change improves data integrity and prevents potential issues related to UBL (Universal Business Language) compliance.
Original PR description
[FIX] account_edi_ubl_cii: Allow only invoices can be grouped Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move no-task Forward-Port-Of: odoo/odoo#255359
This update fixes an issue where users were incorrectly prompted for passwords on encrypted PDFs that didn't actually require them. The system now correctly checks if a password is needed before attempting a download, ensuring a smoother and more reliable experience for users accessing signed documents. This resolves a previous bug that blocked downloads.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5400441 Previously, if a user went to download a document, we would check if it was encrypted. If so, we would redirect to ask for a password. But the problem with that is, not all encrypted documents require passwords. In that case, we would ask for a password when none existed, thus blocking the user from downloading the document. Now we check if a password is required to access the document instead of whether the document is encrypted. That way, we won't redirect to ask for a password when there is no password. Docs about PdfFileReader's `decrypt` method, before and after a major change: https://pypdf2.readthedocs.io/en/2.3.0/modules/PdfReader.html https://pypdf2.readthedocs.io/en/2.12.0/modules/PdfReader.html Forward-Port-Of: odoo/enterprise#102602
This update resolves a bug in the Belgian payroll module that prevented time off requests for Laurie Poiret from being correctly processed. The fix ensures demo data uses the correct company calendar, allowing the Payroll app to accurately reflect time off balances. This improves the reliability of payroll calculations.
Original PR description
### Issue: Laurie Poiret has a calendar belonging to another company. This causes issues in the Payroll app. ### Steps to reproduce: - On runbot, switch to a Belgian company - Create a time off for Laurie Poiret, validate it - In Payroll > Work Entries you can see that the time off is not considered ### Cause: The `resource.calendar.leaves` of the time off belongs to another company, which prevents it from being fetched. This is because at its creation it takes the company of the given calendar. ### Solution: Fix the demo data so that Laurie Poiret has a calendar from the Belgian company. Same for Max Durand. opw-6053558
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
This update resolves an issue where Documents actions weren't appearing correctly when a language was deactivated. The fix ensures that only the currently active language is used when embedding actions, preventing errors and improving the user experience. This ensures consistent functionality across all supported languages.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Activate a second language (e.g., Arabic `ar_001`). 3. Deactivate the Arabic language by active toggle. 3. Go to the Documents app and open a folder 4. Set the 'Action on Select' (cog menu) to embed a server action. Issue: - Action is not selected. Cause: - The method `action_folder_embed_action` uses `_get_stored_translations`, which returns translations for inactive languages as well. This causes an `Invalid language code` error Solution: - Filter the languages retrieved from the DB to ensure only the currently active languages are used. opw-5380645
Features or functions removed from Odoo
This update removes restrictions on which PEPPOL numbers can be used for registration. Previously, only numbers from the PEPPOL list were accepted. Now, Odoo can accept numbers from a wider range of countries, increasing the potential for businesses to participate in the PEPPOL network.
Original PR description
Before this commit, only numbers on the peppol list were able to be registered. Now is possible to add numbers from other countries. Task-6033336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254373