Tuesday, August 11, 2026
14 changes · 19.0
Resolved issues and error corrections
The event calendar test now uses a fixed UTC time zone so it behaves consistently whether demo data is installed or not. This reduces false test failures and helps keep event-related releases more stable.
Original PR description
With demo data, the default event TZ was not UTC. Now the test event tz is set to UTC and the test works with or without demo data. Runbot-945450 Task-6429727
This fixes a chat issue where pressing Escape while viewing who had seen a message closed the entire chat window instead of just the seen-by popup. Users can now dismiss the popup as expected without losing their chat context.
Original PR description
**Steps to Reproduce:** 1. Send a message to Marc demo with Mitchell admin or vice-versa, read the message from reciever's side. 2. Click on seen-by indicator from sender's side, make sure the dialog…
**Steps to Reproduce:** 1. Send a message to Marc demo with Mitchell admin or vice-versa, read the message from reciever's side. 2. Click on seen-by indicator from sender's side, make sure the dialog appears and then Press `'ESC'`. 3. Chat window closes whereas the dialog should have closed. Since #169737, pressing 'esc' on the seen-by dialog closes the chat window instead of the dialog. The chat window's root element has a keydown handler that closes the window on `'escape'`, and catches focus by default whenever something non-focusable is clicked inside it (e.g. the seen-by indicator). The seen-by dialog's content had no focusable element, so it never grabbed focus for itself, leaving focus on the chat window. Pressing 'escape' therefore closed the chat window instead of the dialog. This commit fixes the issue by adding tabindex on the template, letting the dialog grab focus like other dialogs/popovers already do, so `'escape'` is handled by the dialog first. task-4895004 Forward-Port-Of: odoo/odoo#281361 Forward-Port-Of: odoo/odoo#278847
Saudi POS receipts now keep the ZATCA QR code at a consistent visual size, even when the company legal name is long. This makes receipts more uniform and helps avoid dense, harder-to-scan QR codes for businesses with longer names.
Original PR description
Steps to reproduce: - Set a Saudi company with a long legal name (e.g. "Golden Oasis Trading and Contracting Company Limited") - Make a POS order and look at the receipt QR code Issue: The QR code is…
Steps to reproduce: - Set a Saudi company with a long legal name (e.g. "Golden Oasis Trading and Contracting Company Limited") - Make a POS order and look at the receipt QR code Issue: The QR code is drawn visibly smaller and denser than for a company with a short name, even though the image it sits in is the same 150px box: 90px of code at a 2px module pitch, against 111px at 3px. Cause: The ZATCA payload embeds the seller name, so a longer name needs a higher QR version, i.e. more modules. ZXing's BrowserQRCodeSvgWriter draws each module at a whole number of pixels of the canvas it is given (multiple = floor(canvas / (modules + 8))), so asking it for a fixed 150x150 or 200x200 canvas leaves a leftover margin that varies with the module count. The code shrinks as soon as the module count crosses a multiple of the canvas size. opw-6399878 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281036 Forward-Port-Of: odoo/odoo#280000
This fix makes sales and manufacturing test data use a fixed invoicing setting, so results no longer change when certain country-specific modules are installed. It reduces false test failures and helps keep accounting-related validation reliable across localized deployments.
Original PR description
Steps to reproduce the bug: - Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery'…
Steps to reproduce the bug: - Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery' in that case) - Run TestSaleMRPAngloSaxonValuation.test_sale_mrp_kit_bom_cogs (sale_mrp) or TestAngloSaxonValuation.test_anglo_saxon_cogs_partial_down_payment_credit_note (sale_stock) Problem: These tests create their products without setting invoice_policy explicitly, relying on the field's implicit default. l10n_ke_edi_oscu_stock's _compute_invoice_policy (https://github.com/odoo/enterprise/blob/4e459417dac809caafea34aa2e487fc3c1f0ce1a/l10n_ke_edi_oscu_stock/models/product.py#L16-L21) forces invoice_policy to 'delivery' for any storable product whose company_id is not set, which is the case for products created in these test fixtures. Once invoice_policy becomes 'delivery', invoiced quantities are driven by qty_delivered instead of the ordered quantity, which the affected tests never account for (some deliver an arbitrary quantity instead of the exact BoM demand, others never validate a delivery at all), causing wrong COGS amounts or wrongly invoiced quantities as soon as such a localization is installed alongside these modules. Solution: Pin invoice_policy to 'order' explicitly wherever these test fixtures create their products, so the test outcome no longer depends on which other modules happen to be installed. runbot-243633 Forward-Port-Of: odoo/odoo#278891 Forward-Port-Of: odoo/odoo#278346
This fix removes outdated setup data in the repair subcontracting area that could conflict with current records. It helps prevent configuration inconsistencies caused by older refactoring leftovers, with minimal visible impact for everyday users.
Original PR description
An old refactor left some data around that are in conflict with other records for the same model. 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#281276
Odoo now keeps the unread message banner visible when a user is scrolled up in a conversation and a new message arrives. This prevents missed message notifications and makes chat behavior more reliable across devices.
Original PR description
Before this commit, the unread banner of a conversation showed up and disappeared right away when a message arrived while the user was scrolled up in the history. On a busy machine it is never rendered at all, which fails this hoot test:
```
show banner for new message after thread was read from another device
Failed to find 1 of ".o-mail-Thread-banner:has(:text('1 new message'))"
(Timeout of 10 seconds). Found 0 instead.
```
This happens because a message received while the composer has the focus is marked as read whatever the scroll position, while the counter the banner reads is frozen only when the conversation is scrolled to the bottom too. The counter therefore goes up for a scrolled up user, and back to zero as soon as the read reaches the server.
This commit marks a received message as read only when the conversation is scrolled to the bottom, as the other automatic reads already do.
https://runbot.odoo.com/odoo/error/945671
Forward-Port-Of: odoo/odoo#281488This fix limits an internal editor search so it stops at the editable area instead of checking unnecessary page elements. It reduces repeated work during mouse movement, helping the HTML editor feel more responsive without changing user-facing behavior.
Original PR description
#### Description of the issue this PR addresses: - The predicate loop kept climbing ancestors above the editable root when no match was found inside it. The later containment check would discard such a match anyway, so the predicate should never run outside the editable in the first place. - This ran the predicate on at least 14 unnecessary ancestors up to `<html>`, costly if the predicate is expensive. Stop the search at the editable boundary instead. - `movenode_plugin` calls closestElement on every mousemove, so its predicate was needlessly re-evaluated on those 14+ ancestors on every single mouse move. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280011
This fixes an issue where importing translations could produce unpredictable wording when several identifiers referred to the same record. Odoo now consistently applies the later translation entry, improving reliability for translated content updates.
Original PR description
When several xmlids point to the same record, PostgreSQL's UPDATE ... FROM can match multiple source rows to one target and pick an arbitrary value. Aggregate translations per res_id in import order so the later entry wins 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#281365 Forward-Port-Of: odoo/odoo#277818
Opening Bank Matching from a working file could fail when no bank journal was selected. This fix prevents that error, allowing users to continue reconciliation from that flow without interruption.
Original PR description
When accessing the reconciliation widget from the working file check, there is no journal to be selected, hence no journal in the context. This was tracebacking since we were trying to send a read query to the server with an undefined id. To reproduce: * create a bank statement line without reconciling * set up the return on the misc journal * open the return, then "Bank Matching"
The payroll process now correctly checks only payslips that actually have issues before gathering issue details. This prevents incorrect results when a pay run includes both problematic and clean payslips, helping payroll teams review exceptions reliably.
Original PR description
Commit e4e573e1219f38561ae74e2086cee6d54cda6f46 introduced a bug. Steps to reproduce: - Generate a payrun with at least two payslips: one with an issue and another without any issue This commit fixes the issue by filtering the issues payslips before getting their issues. task-5230921
Payroll now correctly finds work entries after a related date-handling change. This helps ensure payslips use the right work entry records and reduces the risk of incorrect payroll calculations.
Original PR description
Since this PR: https://github.com/odoo/odoo/pull/216234, work entries have only a date. This commit fixes the domain.
Documentation and clarification updates
Sahil Singh added an individual contributor license agreement for contributions to the Odoo project. This is a legal housekeeping change that helps ensure recent and future contributions are properly authorized.
Original PR description
Signing the Individual Contributor License Agreement to authorize my recent and future code contributions to the Odoo repository.
This pull request adds a contributor license agreement record for Ci. It is an administrative/legal update that helps keep contribution records complete and does not affect product features or user workflows.
Original PR description
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
A new individual contributor license agreement signature was added for Han Zaw Nyein. This confirms the legal permission needed to accept covered contributions into the project.
Original PR description
Add the individual CLA signature for Han Zaw Nyein (`HanZawNyein`). This signature covers contributions including odoo/odoo#281412 and odoo/odoo#281415.