Daily updates from Odoo
Wednesday, September 3, 2025
5 changes
3 changes
Enhancements to existing features
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
1 change
Enhancements to existing features
Payment memos are now shorter and focus on the transaction reference, with the payment provider transaction ID added when relevant. This removes extra customer details from the memo, making bank reconciliation easier and more reliable.
Original PR description
WIP no-task
1 change
Enhancements to existing features
Odoo can now send message reactions made by users through WhatsApp, so customers see those reactions in their WhatsApp conversations. This keeps conversations more consistent across Odoo and WhatsApp and avoids missing customer-facing context.
Original PR description
Add support for sending reaction type messages via the WhatsApp API by introducing the `reaction` message type in the WhatsAppApi. This resolves the issue where reactions made by Odoo users are not reflected in the customer's WhatsApp conversation. API Documentation: https://developers.facebook.com/docs/whatsapp/cloud-api/messages/reaction-messages Task-4828394 Forward-Port-Of: odoo/enterprise#88520