Tuesday, September 1, 2026
10 changes · 18.0
Resolved issues and error corrections
An older Point of Sale cleanup step was removed because a newer, more targeted fix now handles the issue. This reduces the risk of unintended changes while keeping stale loyalty reward lines properly cleaned up.
Original PR description
This fix is no longer required(https://github.com/odoo/odoo/pull/202752) as this one (https://github.com/odoo/odoo/pull/257043) is cleaner and less aggressive (it will only delete stale reward lines). This is the relevant part of the new fix to delete the previous one: https://github.com/odoo/odoo/pull/257043/changes#diff-18cef42f8c39513a82387e9cb81bc732b252304cd15b5b2f7b0b4623ac20cb41R100-R104 opw-6447092
Invoice PDFs for Guatemala and Uruguay now show the customer identification label that matches the selected ID type, rather than a default country VAT label. This prevents confusion for customers and businesses when invoices use alternative local identification numbers.
Original PR description
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is…
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types. This results in invoice reports showing the identification number next to an incorrect label. This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in their respective invoice template to match the selected identification type. Steps to reproduce: - Install a latam localisation (Uruguay or Guatemala) - Change company to that country's Company - Create a partner located in said country, ensure the identification number is set to something else than the default one - Create an invoice for the partner, confirm it, and then Send it - In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label opw-6087359 related to: https://github.com/odoo/odoo/pull/260159
The Helpdesk team card now aligns the email alias with the team name by removing extra spacing. This provides a cleaner, more consistent layout for users viewing or managing Helpdesk teams.
Original PR description
In this commit, we remove the margin before the mail alias, ensuring aligment within the helpdesk team card. task-6416578
This fixes an internal accounting test so it no longer changes Hungary's currency rounding rules during validation. The change helps prevent false test failures in localized accounting setups without affecting normal business workflows.
Original PR description
The test forced HUF rounding to 1.0, which fails under l10n_hu once HUF has accounting entries. This commit Uses JPY, which already has coarse rounding, instead. [error-946580](https://runbot.odoo.com/odoo/error/946580)
Image upload fields now apply the Android camera workaround only for Android Chromium-based browsers that need it. This prevents other browsers and the mobile app from showing inappropriate file picker options while keeping camera uploads available where Android would otherwise hide them.
Original PR description
Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera`…
Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera` to their accept attribute: a mimetype which is not an image is enough to get the generic chooser, and its camera, back. https://issues.chromium.org/issues/40937303 That invalid mimetype was appended for everyone, while only the browsers based on Chromium on Android need it: - the issue is an Android one, the desktop file dialogs are not concerned - the native app builds its own file chooser out of the accept attribute, and the invalid mimetype makes it offer the document picker on a field which only accepts images - Firefox and Safari are not based on Chromium and are not affected The workaround is now limited to the browsers needing it, and the expression moved from the template to a getter, since it is no longer a simple concatenation. Code made by Claude Supervised by RFR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285643
Responses to invoices received through the French PDP system are now sent through that same PDP channel only, instead of also being sent through the classic Peppol route. This avoids duplicate messages and reduces unnecessary chatter while keeping the invoice response process clearer for users.
Original PR description
When responding to an invoice received through PDP, 2 responses were actually sent: one through PDP and the other through the 'classic' Peppol. This was done to allow more reliability, in case one channel is down when trying to respond, but this mainly creates cluttah' in the chattah' (call me busta rhymes yo) task-6522652 Forward-Port-Of: odoo/odoo#285596
This update corrects how long touch-and-drag actions are handled in Odoo's web testing tools. It prevents an unintended click after a held drag, reducing the risk of tests masking or triggering incorrect interface behavior.
Original PR description
Before this commit, a tap held past `LONG_TAP_DELAY` and released with `drop()` got a click, where the same tap released with `pointerUp()` got none. No test on 18.0 holds a drag that long, so nothing reads that click here. Note that saas-18.3 has one, `selection can be enabled by long touch with drag & drop enabled`, where that click unselects the kanban record the long press just selected. This happens because `drop()` calls the internal `_pointerUp()` without `canBeLongTap`, the flag "[FIX] web: hoot - keep the click of a slow tap on touch" added so that the delay counts only a press the test itself holds. This commit passes that flag from `drop()` too, as a drop is the test releasing the pointer itself.
This fixes a loophole that allowed portal users to change a customer name by creating a different invoice contact. The sales portal now applies the intended restriction consistently, helping preserve accurate customer records linked to sales orders.
Original PR description
Before this commit it was possible to update name by creating an other invoice partner. The AND condition was wrong here.
Fixed an issue where dismissed mention suggestions could reappear and intercept the Escape key, preventing users from closing replies or popups as expected. This makes the mail composer behavior more predictable, especially when suggestions load slowly or the screen refreshes.
Original PR description
Two independent causes made "reply: discard on pressing escape" red, one commit each. "[FIX] mail: wait for the mention suggestions before Escape" is the one that fixes the reported failure, and it holds on every branch: the test presses Escape while the mention fetch is in flight, and the suggestions arriving from the server re-open the list that Escape closed, so the re-opened list takes the second Escape and the reply is never discarded. The test now waits for the fetched suggestions before pressing Escape. "[FIX] mail: keep the suggestion list closed on a re-render" backports "[FIX] mail: keep composer suggestion list closed on unrelated re-render", which entered at 19.0 and never came down. Here NavigableList is re-opened on every patch, so opening the emoji picker after Escape brings the dismissed list back, and it then steals the Escape meant for the picker. https://runbot.odoo.com/odoo/error/946314
Adds a test to ensure batch invoicing for multiple subscription orders keeps each order's own date range separate. This helps prevent invoices from including timesheet entries from the wrong period, improving billing accuracy for subscription services.
Original PR description
A test case to guarantee that batch invoicing multiple orders respects their individual time frames. This test is made to assert the fix in this [PR](https://github.com/odoo/odoo/pull/284781) opw-6507110