Wednesday, June 17, 2026
7 changes · 17.0
Resolved issues and error corrections
This update prevents errors in e-Waybill requests when the dispatch and delivery locations share the same pincode. Previously, the system couldn't automatically calculate the distance in these cases, leading to incomplete requests. Now, a distance must be provided to ensure accurate e-Waybill generation and avoid server issues.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#268497
This update resolves an issue where Odoo would incorrectly mark auto-install modules for installation if a required dependency was missing. Now, if an auto-install module has a dependency that isn't available, it won't be flagged for installation, preventing installation errors and improving database initialization stability.
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
This update resolves a visual inconsistency in email attachments. Previously, buttons with long text labels would render incorrectly in email clients like Gmail, causing text to wrap around the button background instead of maintaining a single box. The change ensures buttons with long text labels display correctly in emails, matching the preview in the editor.
Original PR description
The mail CSS inliner drops every declaration whose name or value contains "flex" because Windows Outlook has no flexbox support. A button styled display:inline-flex therefore loses its display along…
The mail CSS inliner drops every declaration whose name or value contains "flex" because Windows Outlook has no flexbox support. A button styled display:inline-flex therefore loses its display along with the genuine flex declarations. Mail clients fall back to the default display:inline of the <a>, so a button whose label wraps over several lines paints its background, padding and radius around each line of text instead of around the whole box, even though the editor preview still shows a single box. classToStyle and _getMatchedCSSRules in convert_inline.js now map display:inline-flex to inline-block instead of removing it. inline-block is supported across mail clients and keeps an inline element rendered as a single box. The other flex declarations are still removed. Before: <img width="767" height="358" alt="image" src="https://github.com/user-attachments/assets/04ecda63-3041-4e81-888d-744a168ee4d2" /> After: <img width="692" height="457" alt="image" src="https://github.com/user-attachments/assets/4c733885-6124-4b04-b339-00aa9a8e4465" /> Steps to reproduce: 1. In Email Marketing, create a mailing and add a button with a label long enough to wrap over two lines. 2. Open the code view and set the button style to display: inline-flex. 3. Send a test of the mailing and open it in a webmail client such as Gmail. => the button background wraps each line of text instead of forming a single box Ticket [link](https://www.odoo.com/odoo/project.task/6234435) opw-6234435
A recent update to our Weblate translation system unexpectedly reverted some code changes. This pull request is correcting this issue by restoring the previous state of the affected modules. This ensures that our translation workflows continue to function as designed.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit 4894b95a7913fcf8f059b3ec6dbf3d3f5140d62c.
A recent update to our Weblate translation system incorrectly reverted some code changes. This pull request has been implemented to restore the original code, ensuring that future updates don't cause unintended disruptions. This is a minor correction to maintain the stability of our translation workflows.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit bc761f350e309e84ed95527ea7ef901c156c06ee.
This update corrects a technical issue within the Odoo's Danish accounting module (l10n_dk) where an account was listed twice. Removing this duplication ensures accurate financial reporting and avoids potential errors. This change improves the reliability of the accounting data.
Original PR description
In the list 'dk_coa_7630 ', the account has been used in the list twice. Removing the duplication from the list. [Reference](https://github.com/odoo/odoo/blob/17.0/addons/l10n_dk/migrations/1.4/end-migrate.py#L14) 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 allows binary files uploaded through forms to store their filenames, resolving an issue that previously caused incorrect file type detection. This change is important for seamless file uploads and proper functionality, especially for Odoo SaaS modules and future migrations.
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