Wednesday, September 3, 2025
6 changes · saas-18.4
Enhancements to existing features
The demo invoice shown when fetching incoming bills in Peppol demo mode has been replaced with a clearer, more representative example. This helps users better understand what Peppol bill imports look like during demonstrations or testing.
Original PR description
Replace Peppol demo bill that you get when fetching incoming bills in demo peppol mode. Forward-Port-Of: odoo/odoo#225086
Creating records with HTML content now avoids repeating an expensive cleanup step, which can significantly speed up batch operations such as mass mailing. This also reduces memory use during long-running processes, with a small trade-off that reading the same HTML immediately after creation may require an extra database lookup.
Original PR description
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database*…
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database* insertion 2) Once post-insert in `convert_to_cache`, when converting the `vals` for insertion in the *cache* for the newly created records. This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries. To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results. The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make. Benchmark --------- In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were: | Method | Before | After | Speed up | |-------------------------------|----------|-----------|----------| | `_process_mass_mailing_queue` | 2.84 min | 1.55 min | 1.8x | | `create` | 2.11 min | 50.23 sec | 2.5x | This represents roughly a *2x* performance improvement in processing an email campaign. * more detailed benchmarks are available in the task's description Reference --------- task-4962646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224794 Forward-Port-Of: odoo/odoo#223875
The IoT app now includes a test button for the fiscal data module, allowing users to check the blackbox status and see the result immediately in a notification. This helps businesses verify fiscal device connectivity more easily and reduces false connection failures by allowing a slightly longer response time.
Original PR description
This PR adds a "test" button for the fiscal data module in the IoT app. When used it will send a status request to the blackbox and display the result in a notification. It also removes "response_size" supposed to specify how many characters to read in blackbox response which was unused since this PR: https://github.com/odoo/enterprise/pull/87988 task-5055029
Financial reports grouped by account code now also show the matching account name for the current company. This makes consolidated reporting easier to read when multiple accounts from another company are mapped to the same account code.
Original PR description
In the current consolidation, you can make multi-company accounts and assign a code for each company. But a code must be unique inside each company. So it is not designed to map multiple accounts from a second company into one account of a first company. It is actually possible to achieve that effect by not making the accounts of the second company belong to the first company, and still make the code mapping. So you can make several accounts from the second company, map to the same code for the first company. Thus grouping by account codes become interesting for the accounting reports, in order to get a view of that consolidation. In order to make this reporting more clear, the name of the account corresponding to the account code (in the current company) is now shown when grouping by account code. task-4801891 Forward-Port-Of: odoo/enterprise#86403
This update adjusts internal performance test expectations after a backend caching behavior change for HTML content. It helps keep automated checks accurate so teams can continue monitoring Knowledge performance reliably without affecting day-to-day users.
Original PR description
Adapting query count, due to not putting html fields in cache upon creation. task-4962646 Forward-Port-Of: odoo/enterprise#93503 Forward-Port-Of: odoo/enterprise#93171
The Peruvian electronic invoicing setup now shows the updated Estela branding instead of Digiflow in labels, help text, and translations. This keeps customer-facing configuration screens aligned with the provider's current name without changing how invoicing works.
Original PR description
This PR updates the Peruvian electronic invoicing configuration to reflect the recent brand change from Digiflow to Estela (formerly Digiflow). Changes: - Updated help texts and string labels in `res_company.py` - Adjusted references in `account_edi_format.py` - Updated translations in `es.po` This change is purely textual and does not affect logic or behavior. It ensures users see the correct branding across the Peruvian EDI settings. Forward-Port-Of: odoo/enterprise#93649 Forward-Port-Of: odoo/enterprise#85934