Odoo Changelog — 2026-06-25

Thursday, June 25, 2026

6 changes · saas-19.1

Improvements(6)

Enhancements to existing features

[IMP] account: disable check status button if don't have write access

Coresaas-19.1account

The check status button is now disabled for users who do not have permission to update the check. This prevents access errors when the main company is not selected and makes the experience clearer and smoother for users.

Original PR description

Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown.

After this commit: Disable check status button if user don't have write access on check.

task-5951364

#access rights#checks#user experience

[IMP] web: remove :has() selector from dialog draggable

PR #272118

Coresaas-19.1web

This update improves how dialogs are styled so the browser does less work when the page is resized, scrolled heavily, or sorted in tables. The result is smoother performance and quicker visual updates without changing the user experience.

Original PR description

Avoid using the :has() selector and use a specific style on the
`documentElement` instead to replicate the same behavior.
This reduces work during the "Recalculate Style" phase.

It lowers recalculation time during window resizes, heavy scrolling, and
table sorting by preventing broad selector matches and limiting style
checks to elements with the specific class.

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

#performance#dialog#ui#styling

[IMP] hr_expense_stripe: emails for soon-to-be restricted accounts

PR #121716

Enterprisesaas-19.1hr_expense_stripeMedium

Odoo now sends automatic emails to companies when Stripe flags their connected account as at risk of restriction. This gives businesses early warning so they can correct missing documentation or other issues before payments are affected.

Original PR description

When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. 
task: 5441662

Forward-Port-Of: odoo/enterprise#107918

#stripe#email notification#kyc#connected account#compliance

[IMP] *: extension number for belgian iban

PR #117244

Enterprisesaas-19.1account_bank_statement_importl10n_be_codal10n_be_coda_extension_numberl10n_be_codaboxl10n_be_codacleanMedium

A new extension number can now be stored for Belgian bank journals, helping Odoo distinguish between bank journals that share the same account number. This improves the accuracy of CODA statement imports when used with Codabox or Codaclean, reducing the risk of statements being matched to the wrong journal.

Original PR description

Original commit message:

Bank journal can have the same bank account number, to be able to have a difference between them.
We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement.

task-5254158

Backport commit message:

This commit backports the code to handle extension number in stable. Some adaptations were done
to allow this backport.
1. We have a new module for the new field and the view.
2. Except that, the code stays in the existing modules with a condition that check if the extension number is present in the journal's field list. NB: This implementation is pretty bad but the existing code doesn't include hooks to extend to add customization. To avoid a whole refactoring in stable, this approach was chosen.
3. A test and a test file from the codabox module are deleted because we don't want to create a new module for tests only.

task-6116452

Forward-Port-Of: odoo/enterprise#113699

[ADD] base: monkeypatch markupsafe to speedup qweb compilation

PR #271482

Coresaas-19.1baseMedium

This change restores a faster way of processing text cleanup during template compilation, which helps Odoo render some QWeb templates more quickly. It addresses a slowdown introduced by a newer MarkupSafe version, especially for templates with large or complex text content.

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. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 

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 for varying input size.

The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the 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, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either.

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

Benchmarks:

| Case                                      | Regex ms | Current ms | Speedup |
|----------------------------------------------|----------|------------|---------|
| plain_text_50k_words                         | 3.020    | 2.627      | 0.9x ← current_implementation |
| unclosed_tag_then_50kb_text                  | 0.367    | 0.032      | 0.1x ← current_implementation |
| unclosed_tag_then_500kb_text                 | 3.787    | 0.273      | 0.1x ← current_implementation |
| multiple_unclosed_open_tags_then_50kb_text   | 18.912   | 0.371      | 0.0x ← current_implementation |
| multiple_unclosed_open_tags_then_500kb_text  | 189.007  | 8.209      | 0.0x ← current_implementation |
| unclosed_comment_then_500kb_text             | 7.276    | 0.412      | 0.1x ← current_implementation |
| 5k_small_tags                                | 0.986    | 22.096     | 22.4x ← regex_old_implementation |
| 20k_small_tags                               | 4.125    | 492.186    | 119.3x ← regex_old_implementation |
| 50k_small_tags                               | 12.658   | 5499.602   | 434.5x ← regex_old_implementation |
| 1k_nested_divs                               | 0.155    | 0.923      | 5.9x ← regex_old_implementation |
| 10k_nested_divs                              | 1.648    | 48.410     | 29.4x ← regex_old_implementation |
| 2k_tags_with_attrs                           | 1.058    | 12.013     | 11.4x ← regex_old_implementation |
| 20k_tags_with_attrs                          | 13.185   | 6068.755   | 460.3x ← regex_old_implementation |
| 2k_multiline_tags                            | 0.815    | 10.819     | 13.3x ← regex_old_implementation |
| 20k_multiline_tags                           | 8.939    | 4231.768   | 473.4x ← regex_old_implementation |
| 1k_comments                                  | 0.222    | 1.292      | 5.8x ← regex_old_implementation |
| 1k_comments_hiding_tags                      | 0.163    | 1.121      | 6.9x ← regex_old_implementation |
| 2k_mixed                                     | 0.278    | 2.392      | 8.6x ← regex_old_implementation |
| 10k_mixed                                    | 1.400    | 50.959     | 36.4x ← regex_old_implementation |
| qweb_shop_200_products                       | 0.907    | 7.880      | 8.7x ← regex_old_implementation |
| qweb_shop_1000_products                      | 4.296    | 194.647    | 45.3x ← 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

Forward-Port-Of: odoo/odoo#268580
Forward-Port-Of: odoo/odoo#257889

[IMP] account_peppol,l10n_fr_pdp: rework PDP registration

PR #272206

Coresaas-19.1account_peppoll10n_fr_pdpMedium

The registration flow for French e-invoicing has been reworked to better guide users toward the correct PDP setup and to make the process clearer in Send & Print. It also improves the registration wizard by showing key fields earlier, locking verified data, and completing registration automatically after verification, which should reduce confusion and manual steps.

Original PR description

#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
  - "You can send this invoice electronically via Peppol." (what is peppol)
  - "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
  (this warning can be disabled by setting the system parameter
   `account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning

If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
  - it explains what French E-Invoicing is
  - it provides a button to open the registration wizard
  - in case the company is registered on Peppol it deregisters the
    company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
  also for French companies (with the wording and "Peppol Info" mentioned above)
  - It is displayed in case we are opening the Send & Print wizard from a French
    company for a partner on peppol but the "Peppol" / "French
    E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
  the user to register

In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success

task-6320246

#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case

That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.

task-None

Forward-Port-Of: odoo/odoo#271733

Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown. After this commit: Disable check status button if user don't have write access on check. task-5951364

Avoid using the :has() selector and use a specific style on the `documentElement` instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. task: 5441662 Forward-Port-Of: odoo/enterprise#107918

Original commit message: Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement. task-5254158 Backport commit message: This commit backports the code to handle extension number in stable. Some adaptations were done to allow this backport. 1. We have a new module for the new field and the view. 2. Except that, the code stays in the existing modules with a condition that check if the extension number is present in the journal's field list. NB: This implementation is pretty bad but the existing code doesn't include hooks to extend to add customization. To avoid a whole refactoring in stable, this approach was chosen. 3. A test and a test file from the codabox module are deleted because we don't want to create a new module for tests only. task-6116452 Forward-Port-Of: odoo/enterprise#113699

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. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 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 for varying input size. The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the 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, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either. Apart from that, the old implementation is consistently much more performant, for both small and large inputs. Benchmarks: | Case | Regex ms | Current ms | Speedup | |----------------------------------------------|----------|------------|---------| | plain_text_50k_words | 3.020 | 2.627 | 0.9x ← current_implementation | | unclosed_tag_then_50kb_text | 0.367 | 0.032 | 0.1x ← current_implementation | | unclosed_tag_then_500kb_text | 3.787 | 0.273 | 0.1x ← current_implementation | | multiple_unclosed_open_tags_then_50kb_text | 18.912 | 0.371 | 0.0x ← current_implementation | | multiple_unclosed_open_tags_then_500kb_text | 189.007 | 8.209 | 0.0x ← current_implementation | | unclosed_comment_then_500kb_text | 7.276 | 0.412 | 0.1x ← current_implementation | | 5k_small_tags | 0.986 | 22.096 | 22.4x ← regex_old_implementation | | 20k_small_tags | 4.125 | 492.186 | 119.3x ← regex_old_implementation | | 50k_small_tags | 12.658 | 5499.602 | 434.5x ← regex_old_implementation | | 1k_nested_divs | 0.155 | 0.923 | 5.9x ← regex_old_implementation | | 10k_nested_divs | 1.648 | 48.410 | 29.4x ← regex_old_implementation | | 2k_tags_with_attrs | 1.058 | 12.013 | 11.4x ← regex_old_implementation | | 20k_tags_with_attrs | 13.185 | 6068.755 | 460.3x ← regex_old_implementation | | 2k_multiline_tags | 0.815 | 10.819 | 13.3x ← regex_old_implementation | | 20k_multiline_tags | 8.939 | 4231.768 | 473.4x ← regex_old_implementation | | 1k_comments | 0.222 | 1.292 | 5.8x ← regex_old_implementation | | 1k_comments_hiding_tags | 0.163 | 1.121 | 6.9x ← regex_old_implementation | | 2k_mixed | 0.278 | 2.392 | 8.6x ← regex_old_implementation | | 10k_mixed | 1.400 | 50.959 | 36.4x ← regex_old_implementation | | qweb_shop_200_products | 0.907 | 7.880 | 8.7x ← regex_old_implementation | | qweb_shop_1000_products | 4.296 | 194.647 | 45.3x ← 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 Forward-Port-Of: odoo/odoo#268580 Forward-Port-Of: odoo/odoo#257889

#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration If PDP is not installed but Peppol is installed we suggest installing the PDP module for French companies - in the send & print instead of the following warnings - "You can send this invoice electronically via Peppol." (what is peppol) - "partner has requested electronic invoices reception on Peppol." - in the send & print for any French company that is not on PDP (this warning can be disabled by setting the system parameter `account_peppol.disable_pdp_warning` to true) - in the peppol registration wizard by adding a warning If PDP is installed we make the following changes to the send & print - change the wording mentioning "Peppol" to mention the French e-invoicing instead - make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`) - it explains what French E-Invoicing is - it provides a button to open the registration wizard - in case the company is registered on Peppol it deregisters the company first (just like the "complete registration" button) - display the "You can send this electronically via Peppol" warning also for French companies (with the wording and "Peppol Info" mentioned above) - It is displayed in case we are opening the Send & Print wizard from a French company for a partner on peppol but the "Peppol" / "French E-invoicing" checkbox is not checked - Change the wording of the French company non-PDP warning to encourage the user to register In the PDP registration wizard - make all the fields visible directly (already at the start of the KYB/KYC) - make the SIREN part of the identifier readonly - make the fields readonly after the verification - automatically "validate" / register to PDP when we receive the KYC success task-6320246 #### [IMP] l10n_fr_pdp: add system param for kyc siren After the previous commit it is not really possible anymore to use a different SIREN for the KYC than the one in the pdp identifier. This is because: - We derive the SIREN directly from the Identifier in the registration wizard. - The registration will be validated automatically after the KYC - The values are readonly after the KYC in any case That is a problem for testing because we have 1 SIREN to test the KYC and it is independent from the identifiers provided by the French datasets for the PDP test environment. task-None Forward-Port-Of: odoo/odoo#271733