Thursday, June 18, 2026
8 changes · saas-18.4
Resolved issues and error corrections
Creating another tracked link now exits the previous link editing state first. This prevents confusing OK and Cancel buttons from appearing on the next link screen and avoids an error when users click OK.
Original PR description
Steps to reproduce: - Go to the Link Tracker page - Generate a first tracked link - Click on the button to start editing the code - Click on "create another tracker" - Generate a second tracked link => When you access the screen to see/edit the tracked link url, the buttons "ok" and "cancel" are already present. Clicking on "ok" display a traceback. To fix this issue, this commit also cancels edition when clicking on "create another tracker". task-4531974 Forward-Port-Of: odoo/odoo#269886 Forward-Port-Of: odoo/odoo#268573
During new database setup, Odoo now skips optional auto-install modules when one of their required modules is unavailable. This prevents failed or inconsistent installations caused by custom or missing dependencies.
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
Course slide comment tabs now show the correct number of visible comments when comments are added or deleted. This prevents learners and course managers from seeing misleading comment counts, including when internal notes are added in the backend.
Original PR description
Steps to reproduce: - Open a slide of a course in non fullscreen mode (website). - Go to the comments tab and add a comment in the chatter. - The comments count does not change in the tab. - The same thing happens when a comment is deleted. - Another way to see the incorrect counter is to add a note in the slide form view (backend). Before this change, `website_slides` used `website_message_ids` to calculate the comments. Since #138233 the old portal chatter has been replaced with the mail chatter and the way messages are displayed on the portal has changed. For example notes are no longer considered portal messages and also deleted messages should not be displayed or counted as such. This change ensures that comments calculations are based on a domain that considers those changes meaning that comments will be synced with the actual number of available comments. Forward-Port-Of: odoo/odoo#264333 Forward-Port-Of: odoo/odoo#260376
Purchase order lines now preserve very small product costs and vendor prices instead of rounding them too early. This keeps purchase pricing consistent with sales and prevents tiny unit prices from being lost when creating purchase orders.
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
Debit notes generated from invoices now display as “Debit Note” instead of being labeled as invoices. This helps customers and accounting teams clearly distinguish debit notes from standard invoices when printing or sending documents.
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
Files uploaded through website forms will now keep their original filename more consistently, including for standard binary fields. This helps Odoo identify file types correctly later and prevents issues caused by missing filenames.
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
Event communication setup now prevents users from creating WhatsApp templates with the wrong event-related record type. This avoids confusing access errors when reopening an event after saving a WhatsApp communication line.
Original PR description
Issue: 1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add "'no_create_edit': True" to the associated field in the xml to block creation of new mail.templates opw-6037488 Forward-Port-Of: odoo/odoo#268641 Forward-Port-Of: odoo/odoo#259683
This update corrects an issue where sign templates using auto-filled values (like 0 or False) weren't correctly populated. A previous fix unintentionally treated these falsy values as empty, leading to incorrect sign data. Now, the system properly preserves these values, ensuring accurate sign document completion.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the auto field value is 0 or False. - Send the…
Version: - saas-18.4 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the auto field value is 0 or False. - Send the document for signing and try to sign it - Observe that the readonly field is not populated with the auto-filled value. Issue: - Readonly sign items using auto-filled values from a linked record could not be validated when the value was 0 or False. Instead of using these values, the sign item kept its default value. Cause: - A previous fix was added to avoid replacing existing values with empty auto-filled values. However, the check also considered valid falsy values such as 0 and False as empty, so they were not populated into the sign item. Fix: - Only treat empty strings as missing auto-filled values. This allows valid values such as 0 and False to be populated correctly. Since the sign item value is stored in a text field, False is converted to the string "False" before storing it, ensuring it is preserved and correctly available during the signing flow.