Odoo Changelog — 2026-06-05

Friday, June 5, 2026

5 changes · 17.0

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_tr_nilvera_einvoice: binascii.Error when adding PDF to invoice

Core17.0l10n_tr_nilvera_einvoice

This update resolves a technical problem that prevented PDFs from being correctly attached to invoices when using the Nilvera e-invoicing system. The change ensures compatibility with Python 3.14's stricter data validation rules, allowing the system to handle PDF files properly.

Original PR description

This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation.

When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values.

runbot-938173

#invoice#pdf#nilvera#einvoice

[FIX] odoo: improve logger message when translation file load error occurs

PR #184631

Core17.0translate

This update fixes a problem where Odoo's error messages related to translation files were unclear, making it difficult to identify the specific file causing the issue. Now, Odoo logs the exact path of the problematic translation file, significantly improving debugging and troubleshooting for translation errors. This enhances the overall stability and usability of the Odoo platform.

Original PR description

Description of the issue/feature this PR addresses:
#184630
The error message is unclear as to which is the file containing the error.

Current behavior before PR:
Before this commit, Odoo would show a not helpful message like: [lang: es][format: po]
This does not specify or help the developer to locate the file that contains the error.

Desired behavior after PR is merged:
After the commit, we correctly log the path of the file that raised the error.

closes #184630

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#translation#error#logging

[FIX] mass_mailing{,_themes}: stop stretching media list images

PR #238138

Core17.0mass_mailing

This update fixes an issue where images in email marketing templates were stretched and distorted when paired with long text. The change removes unnecessary styling, ensuring images maintain their aspect ratio and fit naturally alongside the text, providing a cleaner and more professional email experience.

Original PR description

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

Ticket [link](https://www.odoo.com/odoo/project.task/5117571)
opw-5117571

#email marketing#templates#image display

Close the extra menu before opening site menu

PR #266376

Core17.0website

This update resolves an issue where updating the extra menu caused the main website menu to unexpectedly close. By closing the extra menu before opening the site menu, the system now behaves consistently and avoids unpredictable errors. This ensures a smoother user experience for website visitors.

Original PR description

[FIX] website: close the extra menu before opening site menu

Update of the extra menu item is done multiple times (cfr
`afterFontsloading`). If the extra menu item and the site menu were
already open before an update of the extra menu item, the result is a
close of the site menu. This can lead to undeterministic error. To solve
the problem, the extra menu dropdown is closed before opening the site
menu.

runbot-240955

#website#menu#user experience

[ADD] base: monkeypatch markupsafe to speedup qweb compilation

PR #261760

Core17.0base

This update optimizes how Odoo compiles QWeb templates, resulting in faster performance. The change addresses a performance issue introduced in Markupsafe version 2.1.4, specifically related to how it handles HTML tags, leading to significant speed improvements for template rendering.

Original PR description

Starting version 2.1.4 of markupsafe, they decided to adapt the striptags function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used striptags with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster.

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better.

The benchmark cases are in the form `<case_description>_<number_of_tags>`. We can see that the only cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                               | Regex µs | Current µs   | Speedup  |
|----------------------------------------|----------|--------------|----------|
| plaintext_no_tags_50k_words            | 2937.05  | 2795.78      | 0.95x ← current_implementation |
| html_entities_only_no_tags_5k               | 4843.88  | 4818.92      | 0.99x ← current_implementation |
| comments_only_1k                       | 382.75   | 1985.56      | 5.19x ← regex_old_implementation |
| comments_containing_tags_1k            | 234.88   | 1243.65      | 5.29x ← regex_old_implementation |
| comments_only_50k                      | 21047.84 | 21081024.01  | 1001.58x ← regex_old_implementation |
| comments_containing_tags_50k           | 13948.90 | 11301014.95  | 810.17x ← regex_old_implementation |
| short_tags_5k                          | 915.32   | 28235.99     | 30.85x ← regex_old_implementation |
| short_tags_20k                         | 3603.37  | 876001.98    | 243.11x ← regex_old_implementation |
| short_tags_50k                         | 10648.04 | 9064394.50   | 851.27x ← regex_old_implementation |
| nested_divs_1k_deep                    | 148.99   | 880.14       | 5.91x ← regex_old_implementation |
| nested_divs_10k_deep                   | 1730.14  | 54162.25     | 31.31x ← regex_old_implementation |
| tags_with_many_attrs_2k                | 1165.15  | 16554.24     | 14.21x ← regex_old_implementation |
| tags_with_many_attrs_20k               | 12659.77 | 7297957.10   | 576.47x ← regex_old_implementation |
| multiline_tags_20k                     | 10227.63 | 5476065.12   | 535.42x ← regex_old_implementation |
| mixed_comments_with_tags_text_2k            | 309.79   | 3034.69      | 9.80x ← regex_old_implementation |
| mixed_comments_with_tags_text_10k           | 1593.39  | 79993.58     | 50.20x ← regex_old_implementation |

This PR is needed because requirements.txt in Odoo specifies the following dependency:
MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#performance#qweb#template

This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173

Description of the issue/feature this PR addresses: #184630 The error message is unclear as to which is the file containing the error. Current behavior before PR: Before this commit, Odoo would show a not helpful message like: [lang: es][format: po] This does not specify or help the developer to locate the file that contains the error. Desired behavior after PR is merged: After the commit, we correctly log the path of the file that raised the error. closes #184630 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The media list snippet forces the image to fill the height of its row. The image column carries align-self-stretch and the image carries h-100, so when the text next to the image is longer than the image is tall, the row grows to fit the text and the image is stretched to that height (and cropped through object-fit: cover). The longer the text, the more the image is distorted. Drop h-100 from the image and align-self-stretch from its column in the s_media_list snippet and in the mass_mailing_themes templates that reuse it. With no forced height the image keeps its natural aspect ratio and the row height follows its content, so the image is laid out next to the text instead of being stretched to match it. Steps to reproduce: 1. Open Email Marketing and create a new mailing. 2. Select the Blogging template for the mail body. 3. In a media item, replace the text next to an image with a very long paragraph. => The image is stretched and cropped to match the height of the text. Ticket [link](https://www.odoo.com/odoo/project.task/5117571) opw-5117571

[FIX] website: close the extra menu before opening site menu Update of the extra menu item is done multiple times (cfr `afterFontsloading`). If the extra menu item and the site menu were already open before an update of the extra menu item, the result is a close of the site menu. This can lead to undeterministic error. To solve the problem, the extra menu dropdown is closed before opening the site menu. runbot-240955

Starting version 2.1.4 of markupsafe, they decided to adapt the striptags function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex. A problem has been spotted with qweb templates that used striptags with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better. The benchmark cases are in the form `<case_description>_<number_of_tags>`. We can see that the only cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, the old implementation is consistently much more performant, for both small and large inputs. Benchmarks: | Case | Regex µs | Current µs | Speedup | |----------------------------------------|----------|--------------|----------| | plaintext_no_tags_50k_words | 2937.05 | 2795.78 | 0.95x ← current_implementation | | html_entities_only_no_tags_5k | 4843.88 | 4818.92 | 0.99x ← current_implementation | | comments_only_1k | 382.75 | 1985.56 | 5.19x ← regex_old_implementation | | comments_containing_tags_1k | 234.88 | 1243.65 | 5.29x ← regex_old_implementation | | comments_only_50k | 21047.84 | 21081024.01 | 1001.58x ← regex_old_implementation | | comments_containing_tags_50k | 13948.90 | 11301014.95 | 810.17x ← regex_old_implementation | | short_tags_5k | 915.32 | 28235.99 | 30.85x ← regex_old_implementation | | short_tags_20k | 3603.37 | 876001.98 | 243.11x ← regex_old_implementation | | short_tags_50k | 10648.04 | 9064394.50 | 851.27x ← regex_old_implementation | | nested_divs_1k_deep | 148.99 | 880.14 | 5.91x ← regex_old_implementation | | nested_divs_10k_deep | 1730.14 | 54162.25 | 31.31x ← regex_old_implementation | | tags_with_many_attrs_2k | 1165.15 | 16554.24 | 14.21x ← regex_old_implementation | | tags_with_many_attrs_20k | 12659.77 | 7297957.10 | 576.47x ← regex_old_implementation | | multiline_tags_20k | 10227.63 | 5476065.12 | 535.42x ← regex_old_implementation | | mixed_comments_with_tags_text_2k | 309.79 | 3034.69 | 9.80x ← regex_old_implementation | | mixed_comments_with_tags_text_10k | 1593.39 | 79993.58 | 50.20x ← regex_old_implementation | This PR is needed because requirements.txt in Odoo specifies the following dependency: MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble) This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe. opw-5999688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr