Wednesday, May 27, 2026
5 changes · 19.0
Enhancements to existing features
This update improves the speed of auditing large financial reports. Previously, navigating back and forth between reports and their details caused slow reloads and blank screens. Now, the system caches report data, speeding up the auditing process and making it more efficient.
Original PR description
When auditing large reports, users often navigate back and forth between the report and its underlying move lines. Each time the user returns to the report, it triggers a full reload, resulting in a blank screen and long wait time making auditing slow and painful. This commit caches the report information, and line expansion rpc calls in disk. RPC calls are being called asynchronously, and the report is updated if data changed. While data is being refreshed in the background, cached report is displayed along with a warning banner informing the user that report is being loaded. task-5145462
Resolved issues and error corrections
This update ensures that when a marketing automation email fails and is retried, it only resends to records within the original campaign filter, not the entire mailing template. Previously, clicking 'Retry' sent emails to all records matching the template, causing unintended distribution. This fix maintains accurate targeting and prevents wasted email sends.
Original PR description
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a…
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a marketing automation campaign with a filter. 2. Add an email activity and start the campaign. 3. Force at least one email to fail. 4. Click Retry on the mailing form. The email is sent to every record matching the mailing template, not just the failed ones. ### Cause When an activity runs, it computes the matching record ids from the campaign filter and calls `action_send_mail(res_ids)` with that explicit list. The Retry button calls `action_retry_failed`, which deletes the failed mails and traces, flips the mailing to `in_queue`, and lets the mass mailing cron resend it. That cron calls `_action_send_mail()` with no ids, so it falls back to the mailing template's own domain, which is unrelated to the campaign filter. ### Fix Override `action_retry_failed` for mailings tied to a marketing activity. Instead of requeuing through the mass mailing cron, reset the failed `marketing.trace` rows back to `scheduled`, cancel their already scheduled children so the next run does not double up, reactivate any participant that was marked `completed`, and trigger the marketing automation cron. That cron runs `execute_on_traces`, which re-applies the campaign filter before sending. Non automation mailings keep the original behavior via `super()`. opw-6010465
This update corrects a bug where refund processing triggered the unintended cancellation of original invoices in the Mexican CFDI module. The fix adds a check to ensure the automatic cancellation flow only applies to invoice replacements, preventing credit notes from causing incorrect cancellations. This ensures accurate financial reporting and avoids disruptions to business operations.
Original PR description
Issue: Implementation of automatic CFDI cancel flow of an invoice substituted by a new one accidentally resulted in sending credit notes created from an invoice also triggering cancellation of the original. Solution: adding a check to only apply to invoice replacements and not refunds. ticket-6245456
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with a large number of sales orders. The fix ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and installation failures.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118203 Forward-Port-Of: odoo/enterprise#118008
This update fixes a problem where users weren't notified when an expense's payment authorization status changed (e.g., cancelled). The update ensures that users receive timely updates about their expenses, improving accuracy and reducing potential issues. This resolves a previous bug where authorization updates were missed.
Original PR description
## [FIX] hr_expense_stripe: Fix error messages coherence Fix the incoherent punctuation ## [FIX] hr_expense_stripe: Fix reversed and expired authorizations Before this, when receiving an `issuing_authorization.updated` event, the event would be ignored and the user would never know that the expense had been cancelled opw-6210055