Monday, August 3, 2026
11 changes · 19.0
Enhancements to existing features
This update improves internal handling of database query building so recommended query patterns can run with less overhead. It supports Odoo's move toward safer, standardized database access without affecting day-to-day user workflows.
Original PR description
This is in preparation for forcefully recommending the use of `execute_query` and `SQL` as early as 19.0. While `execute_query` is the primary recommendation, `execute(SQL(...))` is an OK alternative, but static checking limitations mean queries constructed in function calls, or callers (that includes the implementation of `execute_query` itself), or using conditionals, will be flagged. In that case the easiest pattern is
execute(SQL("%s", query))
which we do not want to penalize overly.
- Add fast path for `SQL("%s", arg: SQL)`.
- Improve fast-path for `SQL(SQL())` to do ~nothing when possible.
- Allow overriding `to_flush` in both case, fix site which needs that
- Update type dispatches to check for `Iterable` instead of `__iter__`. this both helps type checkers and is actually correct.Resolved issues and error corrections
A typo in a Survey view name was corrected to keep upgrade preparation accurate. This minor fix helps ensure future upgrade scripts can reference the view reliably without naming mismatches.
Original PR description
While updating the upgrade script, I found a typo in the view name. The typo occurred during renaming the view name from version 12.4 to 12.5 . It needs to be corrected before the upgrade script can be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Mail issue where the unread message banner could disappear incorrectly in a channel after marking messages as read or reading from another device. Users will now see the banner again when new unread messages arrive, reducing missed messages and confusion.
Original PR description
Before this commit, the unread banner could stop showing in a channel until it was left and opened again: - open a channel with unread messages - click "Mark as Read" - read the same channel from another device - receive a new message: the server counter increases, still no banner This happens because an implicit mark as read freezes the local unread state, so the banner stays in place while the user reads. The problem is that it stays frozen even after the banner is gone, and never follows the server counter again. This commit freezes that state only while something is still unread locally. This also fixes the flaky test "no unread message banner after message is deleted". https://runbot.odoo.com/odoo/error/242776 Forward-Port-Of: odoo/odoo#279601 Forward-Port-Of: odoo/odoo#279195
This fixes the leave attendance report so it uses Odoo's simulated date during automated testing instead of the server's real date. It also updates tests to use relative dates, making them reliable over time and reducing false failures in validation pipelines.
Original PR description
The test for `hr_leave_attendance_report` failed Runbot's faketime tests for two reasons: * The report's view use SQL's reserved syntax `CURRENT_DATE` which always resolves to real system clock, and ignores Odoo's faketime mechanism. * The three tests used hardcoded dates. Since the report is exclusively concerned with the window of last 13 months. Faking the time in a future date further than this led to wrong results. This commit fixes both issues by: 1. Using `now()::date` in the view instead of `CURRENT_DATE`. 2. Replacing the hardcoded dates in the tests by dates computed relative to `fields.Date.today()`. Runbot Errors: [1](https://runbot.odoo.com/odoo/runbot.build.error/944585), [2](https://runbot.odoo.com/odoo/runbot.build.error/944585/runbot.build.error/runbot.build.error/944584)
UK accounting tax totals now show “VAT” instead of the more generic “TAX”, matching standard UK terminology. The subtotal label is also updated to “Subtotal”, making invoices and tax summaries clearer for UK users.
Original PR description
Use "VAT" instead of "TAX" for the default UK tax groups. Also set "Subtotal" as their preceding subtotal label so that it replaces "Untaxed Amount". task-[6413495](https://www.odoo.com/odoo/project/967/tasks/6413495) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278351
This fix prevents the formatting toolbar from briefly appearing at the wrong time when users double-click text and may continue to triple-click. It makes text selection feel smoother and avoids distracting flicker in the HTML editor.
Original PR description
Purpose of this PR: - On double click, opening the toolbar is delayed by 300ms to prevent flickering before a potential triple click. - However, mouseup was re-enabling selection tracking (onSelectionChangeActive = true) before the 300ms delay finished. Because browser selectionchange events are dispatched asynchronously after mouseup, they triggered updateToolbar() immediately, bypassing the 300ms delay. - This fix re-enables selection tracking only after the 300ms debounced update actually finishes. runbot-941543 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278025
The HTML editor now correctly applies text direction changes even when the cursor is on an empty line. This improves editing reliability for users preparing terms, conditions, and other formatted business text.
Original PR description
**Steps to reproduce:** 1. Install Sales app and open any sale order 2. In the "Terms and conditions" text area at the bottom, apply the "/Switch direction" command for an empty block **Issue:** The feature doesn't work when you apply it on an empty line **Why this happens:** Before the fix, the switch-direction logic depended on selected text nodes, and effectively ignored empty content nodes. **Fix:** The problem has been fixed in 19.4 as an [IMP] in this commit 9c97fc464ffba5088642d7699b3e033c1fcc2564, so this is essentially a backport for that fix. opw-6344750 Forward-Port-Of: odoo/odoo#279779 Forward-Port-Of: odoo/odoo#276536
The Malaysian Statement of Account option now appears only for companies based in Malaysia. This prevents users in other countries from seeing or running a country-specific report that does not apply to them.
Original PR description
### Current behavior: After installing `l10n_my_reports`, the Malaysian's Statement of Account button appears on Aged Receivable for every company, and the partner Action "Print Statement of Account" can be run from non-MY companies ### Expected behavior: To avoid user confusion, it is advised to restrict its visibility so that it is only accessible to Malaysia-specific companies ### Steps to reproduce: 1. Install `l10n_my_reports` 2. Switch to a non-Malaysian company 3. Open Invoicing > Reporting > Aged Receivable 4. Observe the "Statement of Account" button on partner lines ### Cause of the issue: Missing checks for 'MY' company country code in UI and print report action ### Fix: - show the Aged Receivable SoA button only when `company_country_code === 'MY'` - guard `action_print_report_statement_account` for non-MY companies opw-6340854
Swiss payroll calculations now round amounts directly to the required 0.05 precision instead of using an indirect method that could create tiny differences. This improves consistency in payslip and declaration values and prevents unnecessary salary change entries caused only by rounding artifacts.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
Appointment cancellation emails are now sent in the language of the customer who booked the appointment, matching the behavior of confirmation emails. This avoids confusing customers with messages in the staff member's language while keeping the old behavior for non-appointment events.
Original PR description
**Problem:** When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation,…
**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.
**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.
**Current behavior:**
The cancellation email is rendered in the organizer's language.
**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.
**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.
**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.
opw-6323179
Forward-Port-Of: odoo/enterprise#124116The barcode workflow test now waits until a transfer is clearly ready to validate before proceeding. This prevents occasional false test failures and helps keep inventory barcode processes stable during updates.
Original PR description
Make sure the validate button has the 'primary-btn' class as it means that the transfer is valid before clicking on it. runbot-939917 Forward-Port-Of: odoo/enterprise#125221 Forward-Port-Of: odoo/enterprise#125005