Thursday, June 18, 2026
7 changes · saas-18.3
Resolved issues and error corrections
This update fixes a potential issue where Odoo would incorrectly try to install auto-install modules if a required dependency was missing. Now, if an auto-install module has a missing dependency, it won't be marked for installation, preventing installation errors and improving the stability of new database setups.
Original PR description
Let's consider an auto-install module `A` having 2 dependencies, one to `base` and the second to custom module `B`. If module `B` is not present in the addons path (i.e is unknown), during a new database initialization module `A` would still be marked as `to install`. This commit ensures that if an auto-install module has a missing dependency, it will not be marked as `to install`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270346
This update ensures that purchase order prices, like sales orders, correctly maintain the precision of low-value product costs (e.g., $0.001235). Previously, these prices were rounded, leading to inaccurate calculations. This change improves the reliability of purchase order pricing and reduces potential discrepancies.
Original PR description
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product…
**Description of the issue/feature this PR addresses:** Odoo 19.0 introduced `min_display_digits` on product price fields, allowing small prices to be stored without forcing the global `Product Price` decimal precision to be increased. For example, a product can have a cost of `0.001235`. The value is kept on the product because `standard_price` uses `min_display_digits="Product Price"`. However, when this product is added to a purchase order line, the purchase price computation still explicitly rounds the computed unit price using the currency decimals and the `Product Price` decimal precision. This is inconsistent with sales: sale order lines preserve very small unit prices correctly. https://github.com/user-attachments/assets/03d13596-d72b-4aee-bd37-7910a5842456 **Current behavior before PR:** A product with `standard_price = 0.001235` keeps that value on the product form. When adding the product to a purchase order line, the computed `price_unit` is rounded by `purchase.order.line`, so the small price is lost. The same issue can happen with vendor prices: a supplierinfo price with more precision than the currency decimals is rounded before being assigned to the purchase order line. **Desired behavior after PR is merged:** Purchase order lines preserve the computed unit price precision, just like sale order lines already do. A product cost or vendor price such as `0.001235` remains `0.001235` on the purchase order line instead of being rounded to currency/Product Price precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269066 Forward-Port-Of: odoo/odoo#267664
This update resolves an issue where website interactions were missing events due to asynchronous processing. The fix now buffers and replays missed events, enhancing the stability and reliability of website tours and interactions. This reduces potential instability and improves the overall user experience.
Original PR description
Interactions are meant to be small piece of code that attaches themselves to some part of the current page in a website. They have a lifecycle, in which, we only attach event listeners after the interaction had the time to prepare itself (with willStart). The problem is that since it is asynchronous, all real events that may be dispatched in the meantime will be ignored. In this commit, we simply keep track of all click events and call each corresponding handler if necessary. It should help reduce instability in tours. 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 update fixes a visual issue where debit notes generated as PDFs incorrectly displayed 'INVOICE' instead of 'DEBIT NOTE'. This change ensures that invoices and debit notes are clearly differentiated in printed and emailed documents, improving clarity for customers and internal teams. The fix was driven by a customer request to improve the presentation of debit notes.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
This update resolves an issue preventing users from utilizing the 'today' date operator within Odoo automation workflows. The fix adds the necessary 'context_today' value to the automation's execution context, ensuring the automation functions correctly based on the current date. This improves automation flexibility and functionality.
Original PR description
Steps: - Install web_studio and base_automation - Create a new automation - - Example: Update record on create - - Example: Apply on (`created_on = today`) - Trigger this automation - traceback context_today is undefined. Fix similar to https://github.com/odoo/odoo/pull/204172 base_automation uses safe_eval with a custom context which is missing `context_today` value, this fix add it. It also remove `.to_utc()` since it's purely client-side and this notion doesn't exist in the python server opw-6227927
This update ensures that binary files uploaded through forms now correctly store their filenames. Previously, this feature was limited to manual fields, causing issues with mimetype guessing and potential problems when migrating SaaS modules. This change improves the reliability of file uploads and supports broader usage across Odoo.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268014
This update fixes a potential issue related to how Odoo handles direct debit mandates for bank partners. The change adds a constraint to ensure that direct debits are only created for partners with valid bank accounts, improving data accuracy and reducing the risk of errors in payment processing. This enhances the reliability of our SEPA direct debit functionality.
Original PR description
Forward-Port-Of: odoo/enterprise#120921 Forward-Port-Of: odoo/enterprise#120901