Daily updates from Odoo
Thursday, June 18, 2026
10 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue preventing users with Sales access from inserting data into Quotation templates via the spreadsheet management feature. The change adds a setting to ensure the necessary flag is activated when the module is installed and the user has the appropriate permissions. This improves usability for Sales teams.
Original PR description
Current behavior before PR: - The `can_insert_in_spreadsheet` session flag was not set by the spreadsheet_sale_management module. - Users with proper Sale access rights still could not insert into Quotation templates. Desired behavior after PR is merged: - Added logic to set `can_insert_in_spreadsheet` when the module is installed and the user has the required access rights. Task: [5960761](https://www.odoo.com/odoo/project/2328/tasks/5960761) Forward-Port-Of: odoo/enterprise#120903 Forward-Port-Of: odoo/enterprise#108674
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 resolves an issue where creating RFQ approval requests could trigger access errors when using supplier pricelists with inaccessible vendors. The fix ensures that the system correctly handles vendor access restrictions, preventing errors during approval request creation. This improves the reliability of the approval process.
Original PR description
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two…
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two companies A and B and two users u1 and u2 - user u2 only have access to company A - With user u1: - Create two vendors v1 and v2 without any company assigned - Create vendor pricelists for a product for each vendor and assign the company A to the pricelist - Add the company B for the vendor v2 - With user u2: - Open approval application - Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected) - Save it -> An access error is thrown **Cause** Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`. opw-6203910 Forward-Port-Of: odoo/odoo#269552
This update resolves an issue where creating RFQ approval requests could trigger access errors when using supplier pricelists with inaccessible vendors. The fix ensures that the system correctly handles vendor access restrictions, preventing errors and improving the approval process for users with limited vendor visibility. This improves the reliability of the approval workflow.
Original PR description
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two…
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two companies A and B and two users u1 and u2 - user u2 only have access to company A - With user u1: - Create two vendors v1 and v2 without any company assigned - Create vendor pricelists for a product for each vendor and assign the company A to the pricelist - Add the company B for the vendor v2 - With user u2: - Open approval application - Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected) - Save it -> An access error is thrown **Cause** Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`. opw-6203910 Forward-Port-Of: odoo/enterprise#120251
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