Odoo Changelog — 2026-07-23

Thursday, July 23, 2026

7 changes · saas-19.4

Improvements(7)

Enhancements to existing features

[IMP] account_payment: Allow batch creation for non SEPA payments

Enterprisesaas-19.4account_online_paymentMEDIUM

Users can now create payment batches from the payment list wizard for payment methods beyond SEPA. SEPA payments keep the existing process, ISO payments can produce downloadable XML without payment initiation, and other methods can be grouped into batches without XML.

Original PR description

Since the new payment initiation features, we added a wizard
in the payment list view to allow users to create a batch
or start a payment initiation.

But this was only possible for SEPA payments. This commit
allows users to create batch payments from this wizard with
any payment methods.

This works like so:
- If SEPA payment -> same as before
- If any ISO payment -> Not allowed to initiate the payment but
  can download XML
- If any other methods -> Just allowed to create a batch without
  XML

task-6272798

Forward-Port-Of: odoo/enterprise#120976

#payments#batch payments#payment initiation

[IMP] event_iot: add A4 badge support

PR #123799

Enterprisesaas-19.4event_iotpos_event_iotMEDIUM

Event registration desks can now print attendee badges as A4 PDF documents, making badge handling easier for events that use standard paper printers. The same badge printing option is also available from Point of Sale, supporting smoother on-site operations for large events such as OXP Kenya.

Original PR description

This PR adds the support for A4 pdf badge printing through the registration desk.

Requested for OXP in Kenya

See https://github.com/odoo/odoo/pull/275021

Forward-Port-Of: odoo/enterprise#123478

#events#badges#printing#point-of-sale

[IMP] orm: garbage-collect idle registries to bound memory

PR #276581

Coresaas-19.4bus

Original PR description

On a server with ~2500 databases, the soft limit is reached at ~180 resident databases while the LRU could still hold ~210, so HTTP workers were being recycled under normal load.

Tracking usage
--------------
Every request for a registry goes through the single lookup in the registry constructor, which now stamps it with a monotonic timestamp; the stamp is also set when a registry is first built.

Collecting idle registries
--------------------------
A collection pass drops every registry whose last use is older than the configured idle timeout. It runs at the end of registry loading, so it fires periodically as databases come and go.

Registries that are still loading are skipped, so a concurrent build is never collected. Dropping a registry only detaches it from the LRU: a request still holding a reference keeps working, and the next lookup rebuilds it.

The timeout is read from ODOO_REGISTRY_MAX_IDLE_TIMEOUT, in seconds; a value of zero, the default, disables the mechanism so behaviour is unchanged unless it is opted into.

Results
-------
With a five-minute timeout on the same ~2500-database server, the HTTP workers settle at around 40 resident registries instead of saturating memory on the long run. The gevent worker, which sees every web client reconnect at startup and briefly fills the LRU with ~150 databases, releases most of them on the first pass, reclaiming the memory.

On a real-life SaaS server with 64GB of RAM, that frees up to ~10GB which were previously taken by unused registries in the LRU. It comes at the expense of extra registry recomputes, but on the other hand workers do not reach their virtual memory limit anymore.

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

[IMP] mail: mute unlink logs for last interest and cron triggers

PR #277432

Coresaas-19.4mail

Unlink operations are logged by default, which is useful for auditing most records. However, unlink operations on last interest records and cron triggers happen frequently and provide little auditing value. This PR mutes the unlink logger for these records to avoid filling the logs with repetitive entries, especially when a large number of messages are posted in parallel. task-6400122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Original PR description

Unlink operations are logged by default, which is useful for auditing most records. However, unlink operations on last interest records and cron triggers happen frequently and provide little auditing value.

This PR mutes the unlink logger for these records to avoid filling the logs with repetitive entries, especially when a large number of messages are posted in parallel.

task-6400122



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

[IMP] l10n_fr_pdp: Warn the user when auth process is ongoing

PR #277977

Coresaas-19.4l10n_fr_pdp

Before this commit, when an authentication process was ongoing it was not very clear to the user This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted. task-6372665 Forward-Port-Of: odoo/odoo#277074 Forward-Port-Of: odoo/odoo#275230

Original PR description

Before this commit, when an authentication process was ongoing it was not very clear to the user
This commit adds a banner to warn the user to not cancel the ongoing process or it will be aborted.

task-6372665

Forward-Port-Of: odoo/odoo#277074
Forward-Port-Of: odoo/odoo#275230

[IMP] web: update owl to v3.0.0-alpha.44

PR #276922

Coresaas-19.4html_builderweb

Release notes: https://github.com/odoo/owl/releases/tag/v3.0.0-alpha.44 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

Original PR description

Release notes:
https://github.com/odoo/owl/releases/tag/v3.0.0-alpha.44

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

[IMP] core: automatically use an InMemoryCache with the zeep library

PR #277592

Coresaas-19.4l10n_es_edi_siil10n_es_edi_verifactu

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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 Forward-Port-Of: odoo/odoo#276755 Forward-Port-Of: odoo/odoo#267482

Original PR description

Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call.

opw-6237180

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

Forward-Port-Of: odoo/odoo#276755
Forward-Port-Of: odoo/odoo#267482

Since the new payment initiation features, we added a wizard in the payment list view to allow users to create a batch or start a payment initiation. But this was only possible for SEPA payments. This commit allows users to create batch payments from this wizard with any payment methods. This works like so: - If SEPA payment -> same as before - If any ISO payment -> Not allowed to initiate the payment but can download XML - If any other methods -> Just allowed to create a batch without XML task-6272798 Forward-Port-Of: odoo/enterprise#120976

Motivation ---------- Each database served keeps a full registry in a process-wide LRU. The LRU is bounded by a count, so on a server hosting thousands of databases the number of retained registries follows traffic rather than memory pressure. Their combined footprint can push a worker past its virtual-memory soft limit, at which point it is killed and restarted. On a server with ~2500 databases, the soft limit is reached at ~180 resident databases while the LRU could still hold ~210, so HTTP workers were being recycled under normal load. Tracking usage -------------- Every request for a registry goes through the single lookup in the registry constructor, which now stamps it with a monotonic timestamp; the stamp is also set when a registry is first built. Collecting idle registries -------------------------- A collection pass drops every registry whose last use is older than the configured idle timeout. It runs at the end of registry loading, so it fires periodically as databases come and go. Registries that are still loading are skipped, so a concurrent build is never collected. Dropping a registry only detaches it from the LRU: a request still holding a reference keeps working, and the next lookup rebuilds it. The timeout is read from ODOO_REGISTRY_MAX_IDLE_TIMEOUT, in seconds; a value of zero, the default, disables the mechanism so behaviour is unchanged unless it is opted into. Results ------- With a five-minute timeout on the same ~2500-database server, the HTTP workers settle at around 40 resident registries instead of saturating memory on the long run. The gevent worker, which sees every web client reconnect at startup and briefly fills the LRU with ~150 databases, releases most of them on the first pass, reclaiming the memory. On a real-life SaaS server with 64GB of RAM, that frees up to ~10GB which were previously taken by unused registries in the LRU. It comes at the expense of extra registry recomputes, but on the other hand workers do not reach their virtual memory limit anymore. 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