Daily updates from Odoo
Wednesday, June 24, 2026
9 changes · 17.0
Resolved issues and error corrections
This update fixes a potential issue where WhatsApp messages were being created multiple times due to retry attempts from the WhatsApp Cloud API. The change adds a check to ensure a message isn't created twice, preventing data inconsistencies and improving the reliability of WhatsApp integrations. This ensures accurate message delivery and avoids potential errors.
Original PR description
When Meta's WhatsApp Cloud API does not receive a fast acknowledgment, it retries the webhook delivery with the same msg_uid. The handler was attempting to INSERT a duplicate whatsapp.message record, violating the whatsapp_message_unique_msg_uid constraint. Fix: Add an existence check on msg_uid before creating the record to make the handler idempotent under Meta's retry pattern. opw-6055334
This update fixes a performance issue within the Odoo gevent server by ensuring it properly initializes database registries. Previously, the server wasn't setting registry sizes, leading to slower performance. This change directly addresses a technical optimization for improved server responsiveness.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that partner bank accounts are usable within all child companies, even if the partner is associated with a parent company. Previously, this functionality was limited, causing potential disruptions for users managing multiple company branches. This change improves efficiency and simplifies bank account management across the Odoo system.
Original PR description
Even when a partner has the 'company_id' filled with the parent company, his bank account should be usable in the child companies. This was done in odoo/odoo#262173 from 19.2 but we need to backport it in stable task-6309694
This change resolves an issue where SVG images uploaded by users without write access to system views were not displayed correctly. The fix ensures that SVG attachments are properly processed, preventing a technical error and ensuring knowledge articles display images as intended. This improves the user experience for adding and managing content.
Original PR description
__Current behavior before commit:__ When an SVG attachment is uploaded by a user that has no `write` access to `ir.ui.view`, its mimetype is set to `text/plain`[1] for security reasons (prevent XSS…
__Current behavior before commit:__ When an SVG attachment is uploaded by a user that has no `write` access to `ir.ui.view`, its mimetype is set to `text/plain`[1] for security reasons (prevent XSS attacks). Now because the mimetype is not in `SUPPORTED_IMAGE_MIMETYPES`, `image_src` will be set to `False`[2]. This results in a traceback when the frontend tries to call `startsWith` on `image_src`[3]. __Description of the fix:__ Add the mimetypes in `attachmentsDomain` so it only fetches the images (like it's done in the [overridden getter][4]). __Steps to reproduce the issue on runbot:__ - Make sure Marc Demo has not write access to `ir.ui.view` (remove him from the group **Website / Editor and Designer**) - Log in with Demo - Go to a knowledge article - Add a cover and upload an SVG image -> the image is not displayed - Click on **Replace cover** - Search for the name of the previous SVG file - `TypeError: attachment.image_src.startsWith is not a function` [1]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/odoo/addons/base/models/ir_attachment.py#L378 [2]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/models/ir_attachment.py#L41 [3]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/static/src/components/media_dialog/image_selector.js#L222 [4]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/static/src/components/media_dialog/image_selector.js#L108 opw-4701372
This update resolves an issue where private tasks could be incorrectly designated as parent tasks. This change ensures that private tasks remain truly private and prevents confusion or unintended hierarchical relationships within project management. This improves data integrity and simplifies project organization.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141
This update strengthens the website's stock notification system by preventing unauthorized subscriptions for unavailable products and blocking users from subscribing using another user's email. This enhances security and protects against potential misuse of user accounts.
Original PR description
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This…
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts. Current behavior before PR: - Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock). - Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user. - No validation is enforced, leading to potential security issues. Desired behavior after PR is merged: - Adding a subscription for a non-existent or unavailable product raises a ValidationError. - Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first. - Backend validation prevents misuse of registered user emails and improves security. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where GSTR-1 reports for SEZ invoices in foreign currencies incorrectly displayed invoice values in USD. Now, the reports accurately reflect the invoice value in the company's reporting currency (INR), ensuring accurate tax reporting for Indian businesses using Odoo Enterprise.
Original PR description
Currently, when generatign GSTR-1 return spreadshee, SEZ invoices issued in a foreign currency are exported with their totals in the foreign currency rather than the company currency (INR) Steps to reproduce: - Create a B2B SEZ invoice in foreign currency - Go to Accounting > Reporting > [India] GST Return periods - Generate the GSTR-1 report for the period Issue: In the resulting spreadsheet, the "Invoice Value" column takes the invoice total in USD rather then INR opw-6292913
An upgrade issue in the Italian tax reporting module (l10n_it) was resolved due to changes in report expression formulas. The upgrade process triggered a database constraint violation when attempting to update expressions, which was addressed by adding a migration script to remove outdated expressions before the upgrade.
Original PR description
Steps to reproduce: - Create a database with `l10n_it_reports` on a version before PR #264294 - Switch to current `17.0` - Upgrade module `l10n_it` - An error is raised Upgrading a database with `l10n_it_reports` installed raises an error if the database was created before that PR In that PR, we modified the formulas of several report expressions to use subformulas instead of simple aggregations. During upgrade, the ORM attempts to insert the updated expressions while the old ones still exist, violating the UNIQUE constraint on `(report_line_id, label)` in `account.report.expression` Only happens on upgrade, not on a fresh install. A migration script is added to delete the outdated expressions before the upgrade runs Ticket [link](https://www.odoo.com/odoo/project.task/6299385) opw-6299385
This update optimizes the process of forecasting stock information, specifically for large inventories. By removing an inefficient loop, the system now responds much faster when accessing manufacturing orders, leading to improved overall performance. This change reduces delays and enhances the responsiveness of the stock management system.
Original PR description
Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being…
Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up. ## Benchmarks: |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |6,262 |0.13s |68 |0.12s |68 | |68,882 |0.60s |112 |0.58s |109 | |432,317 |5.49s |398 |3.68s |309 | |757,702 |15.33s |1,141 |5.79s |599 | [opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)