Wednesday, September 2, 2026
23 changes · 19.0
Enhancements to existing features
The mail module now formats warranty information in a standard JSON format before sending it to Odoo's warranty service. This makes the data easier for the receiving service to read reliably and reduces the chance of processing issues.
Original PR description
Format the publisher warranty message using json.dumps() instead of Python's native str() representation. This ensures serializeid JSON serialization for the payload sent to the warranty server. Forward-Port-Of: odoo/odoo#285632 Forward-Port-Of: odoo/odoo#283139
Resolved issues and error corrections
Fixes an issue where the website builder showed an inaccurate preview for the header width setting on boxed header layouts. This helps users make design changes with confidence because the applied setting now matches the selected header type.
Original PR description
The header width option is not previewed properly on the header template `template_header_boxed`. This happens because this template is not compatible with the action `previewableWebsiteConfig` (its width can't be previewed by adding a single class). This commit fixes the problem by using the action `websiteConfig` instead of `previewableWebsiteConfig` when this template is set. task-6420611 Forward-Port-Of: odoo/odoo#282311
Code cleanup and technical improvements
Factur-X e-invoice exports now use a structured internal data format to generate XML instead of the previous template-based approach. This should make the export process easier to maintain and extend, with no intended change for end users.
Original PR description
*= account_edi_ubl_cii_tax_extension, l10n_account_edi_ubl_cii_tests. Refactoring of the export of factur-x. The export now relies on a dict of nodes, and uses the function `dict_to_xml` to generate the xml instead of relying on a qweb template. task-5999127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261572
The website editor’s block search field now shows a pointer cursor when users hover over the clear icon in browsers that display it. This small usability fix makes it clearer that the icon can be clicked to clear the search text.
Original PR description
Steps to reproduce: - Open the website editor. - Open the "Insert a block" dialog. - Enter text in the search bar. - Hover over the clear icon. => The cursor does not indicate that the icon is clickable. Before this commit, the search clear icon kept the default cursor. After this commit, the clear icon uses a pointer cursor to indicate that it is clickable. Note that Firefox does not natively add this clear icon to search inputs, unlike Chrome. This fix only affects browsers that render it. task-6259086
This fixes online point-of-sale payments so they are not incorrectly treated as adjustable when restaurant features are enabled. It helps prevent tips or payment adjustments from being applied to online payment lines by mistake.
Original PR description
In commit ea56e09c1adb, the `canBeAdjusted` override on `PosPayment` was accidentally replaced with `cancelPayment`. However, `canBeAdjusted` is required when `pos_restaurant` is installed to prevent online payment lines from being treated as adjustable (for tips/adjustments). This commit restores `canBeAdjusted` returning `false` for online payments and removes the unused `cancelPayment` method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The appointment bookings calendar now opens on the next upcoming booking instead of jumping to the most distant future booking. This helps staff quickly see the most relevant schedule when managing appointment types, while preserving existing booking list behavior.
Original PR description
Problem: The bookings calendar of an appointment type opens on the week of the most distant booking instead of the next one, even when a booking exists later the same day. Cause:…
Problem: The bookings calendar of an appointment type opens on the week of the most distant booking instead of the next one, even when a booking exists later the same day. Cause: `action_calendar_meetings` sets the landing date from `appointments[0].start`, where `appointments` is `self.meeting_ids.filtered_domain(domain)`. `calendar.event` is ordered on `start desc` and a one2many is read in the order of its comodel, so the first record is the furthest booking rather than the next one. The original `search([...], order='start')` was replaced by the one2many in 14b5caccc325 (odoo/enterprise#23191). Solution: Sort the filtered bookings on `start` in `action_calendar_meetings`. That method is the only place the initial date is built, and `action_calendar_event_view_request` reuses it for the gantt start date, so both entry points are covered. `calendar.event` keeps its `start desc` order, which the booking list views rely on. Steps to reproduce: - Go to Appointments. - Open the appointment type "Schedule a Demo" and click Appointments. - Click New, set the date to later today, save and go back. - Click New, set the date to one year from now, save and go back. - Go back to Appointments, reopen "Schedule a Demo" and click Appointments. - Switch to the calendar view. - Observe that the calendar opens on the week of the booking one year from now. Ticket [link](https://www.odoo.com/odoo/project.task/6480029) opw-6480029
This fixes how event ticket purchase limits are calculated when a ticket or slot is sold out. Sold-out options now correctly show zero availability instead of being treated as if the normal maximum order limit still applies, reducing the risk of incorrect booking behavior for future sales flows.
Original PR description
### Steps to reproduce: event = env['event.event'].create({ 'name': 'Repro Event', 'date_begin': '2026-09-01 08:00:00', 'date_end': '2026-09-01 18:00:00', }) ticket =…
### Steps to reproduce:
event = env['event.event'].create({
'name': 'Repro Event',
'date_begin': '2026-09-01 08:00:00',
'date_end': '2026-09-01 18:00:00',
})
ticket = env['event.event.ticket'].create({
'event_id': event.id,
'name': 'VIP',
'seats_limited': True,
'seats_max': 1,
})
env['event.registration'].create({
'event_id': event.id,
'event_ticket_id': ticket.id,
'name': 'Attendee 1',
'state': 'open',
})
ticket.seats_available -> 0
ticket.is_sold_out -> True
result = ticket._get_current_limit_per_order(event=event) print(result) # {ticket.id: 30} -- expected {ticket.id: 0}
### Issue and Expected
`_get_current_limit_per_order()` used `if not seats_available:` to detect the "no limit" case returned by `_get_seats_availability()`. That check is truthy for both `None` (genuinely no limit) and the integer `0` (fully booked), so a sold-out ticket/slot combination was incorrectly treated as unlimited and returned `limit_max_per_order or EVENT_MAX_TICKETS` (e.g. 30) instead of `0`.
### Fix
`_get_seats_availability()` explicitly documents `None` as the "no limit" sentinel, with `0` meaning "constrained, zero seats left". Use `seats_available is None` to preserve that distinction instead of a falsy check.
No functional regression was found in the current website_event flow: sold-out slots/tickets are filtered or re-derived independently before reaching this value in every existing UI path. This fixes the underlying contract of the method itself, so future or additional callers don't inherit the wrong value.
https://github.com/odoo/odoo/issues/284098
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prProduct image thumbnails now remain evenly sized and centered when auto-cropping is disabled. This keeps product pages looking consistent and makes thumbnail selection easier for shoppers, even when images have very different shapes.
Original PR description
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below…
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below the image. => The wide thumbnail sits at the top of its slot, with blank space under it. Root cause: =========== Thumbnails are given a fixed width of 64px and take their height from `aspect-ratio: var(--o-wsale-product-image-ratio)` [1]. With cropping disabled that variable is `auto`, so each thumbnail keeps the shape of its own image and they no longer share a height. They sit in a flex row, which stretches every slot to the height of the tallest one. The image inside keeps its own height and stays at the top of the slot, so a wide image leaves the rest of its slot empty. The slots are only stretched when the images differ in height, which is why the problem needs cropping to be disabled, and why it does not appear when every image is a landscape one. - [1] sized the thumbnails from the image ratio. Fix: ==== Center the thumbnails in the row so each one keeps the height of its own image instead of being stretched to the tallest. Their width stays at 64px, so a row of wide images still takes the same space as before and none of them is pushed out of the container. [1]: 670b1daa2254 opw-6472484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The helpdesk team card now displays the email alias aligned with the team name. This small visual fix makes the interface cleaner and easier to read for users 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 Forward-Port-Of: odoo/enterprise#129865
The Romanian tax return previously shown as "Tax" is now labeled "D300". This makes it easier for users to identify the correct declaration when selecting or generating tax returns.
Original PR description
Before this commit: When generating a Romanian tax return, one of the return types in the list was labeled "Tax", which was too generic to know which specific tax declaration it referred to. After this commit: The tax return is now renamed to "D300", making it easy to identify this return in the list instead of seeing a generic "Tax" label. task - 6388087
This fixes a timing issue in the Mail app where the suggestion list could reopen after being dismissed, causing the Escape key to close the wrong item. Users should see more reliable reply dismissal behavior, and automated checks should be less prone to false failures.
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 Forward-Port-Of: odoo/odoo#285927 Forward-Port-Of: odoo/odoo#284725
This fixes a crash that could happen when creating a repair from a helpdesk ticket after the returned product was changed. The system now handles cases where the return item no longer matches the ticket product, allowing users to continue the repair workflow without an error.
Original PR description
## Steps to Reproduce: - Install the `helpdesk_repair` module. (with demo data) - Open the ticket titled **"Cabinet Colour and Lock aren't proper"**. - Go to Returns and change the product in Operations. - Click the "**Repair**" button on the ticket. ## Error: `IndexError - tuple index out of range` ## Cause: When the product on the picking does not match the ticket's product, the filtered picking recordset is empty. Accessing `[-1]` on an empty recordset raises an _IndexError_. ## Fix: Use `[-1:]` instead of `[-1]` when retrieving the matching picking, so an empty recordset is handled. sentry-7692929099
Users adding a certificate key file will no longer see a misleading error when they leave the password field empty. The warning now appears only when a password was entered but is incorrect, reducing confusion during certificate setup.
Original PR description
When adding a key file without entering a password, an error banner is immediately displayed, incorrectly suggesting that the password may be invalid. Only show the error banner when a password was provided and is incorrect. Also refactored the compute function to avoid repeated try-except blocks. task-6299175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283589
This fixes a setup omission so the Greek e-invoicing module is included in Odoo's translation workflow. It helps ensure users can receive translated text for this module in supported languages.
Original PR description
Commit https://github.com/odoo/odoo/commit/45bd522dde7a67194e14a40d66944a2e34d1f79d introudced a new module without it's related `weblate.json` entry. This commit fixes this omission. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285570
This update ensures the Indian stock localization installs the accounting-stock dependency it already relies on. It prevents test and setup failures when related e-waybill stock screens need country information from stock accounting.
Original PR description
The view 'l10n_in_ewaybill_stock.view_picking_form_inherit_ewaybill' is broken in single-app tests because it depends on stock.picking:country_code. That field is provided by module 'stock_account' through auto_install relationship. 'stock_account' auto_installs with 'stock' and 'account' installed. This condition exists on stable so it's safe to add this dependency. The dependency is added to l10n_in_stock because it seemed like the logical place where 'account' and 'stock' functionality comes together. [l10n_in_ewaybill_stock] ──[depends]──> [l10n_in_stock] [l10n_in_stock] ──[depends]──> [stock] [l10n_in_stock] ──[depends]──> [l10n_in] ──[depends]──> [account_tax_python] ──[depends]──> [account] REF Runbot: https://runbot.odoo.com/odoo/error/945482 Forward-Port-Of: odoo/odoo#284990
This fix makes Odoo’s PDF tools expose a needed PDF page component consistently across supported PDF library versions. It reduces version-related test failures and helps keep PDF-related maintenance more reliable without changing user-facing behavior.
Original PR description
Prior to this commit, `PageObject` was not re-exported by `odoo.tools.pdf`, forcing tests to patch internal module paths like `PyPDF2._page.PageObject`. This resulted in test failures depending on the installed PDF library version: - `pypdf` (>= 3.0.0): `PyPDF2` submodules no longer exist. - `PyPDF2` 1.x: `PageObject` resides in `PyPDF2.pdf` rather than `PyPDF2._page`. To resolve this, this commit re-exports `PageObject` through `odoo.tools.pdf` across all backend wrappers. runbot-946795
This fixes internal Sign module tests so they work consistently with different supported PDF library versions. It helps prevent avoidable test failures during maintenance and upgrades, without changing the user-facing signing experience.
Original PR description
Prior to this commit, `PageObject` was not re-exported by `odoo.tools.pdf`, forcing tests (such as `test_origin_offset_translation` in `sign`) to patch internal module paths like `PyPDF2._page.PageObject`. This resulted in test failures depending on the installed PDF library version: - `pypdf` (>= 3.0.0): `PyPDF2` submodules no longer exist. - `PyPDF2` 1.x: `PageObject` resides in `PyPDF2.pdf` rather than `PyPDF2._page`. To resolve this: - `PageObject` has been re-exported through `odoo.tools.pdf`. - Update `test_origin_offset_translation` to import `PageObject` via `odoo.tools.pdf` and use `patch.object` with standard attribute names (`cropbox`, `add_transformation`). runbot-946795
French PDP invoice responses are now sent through a single response channel instead of both PDP and classic Peppol. This avoids duplicate messages in invoice discussions while keeping the response flow 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
The editor now removes truly empty columns when users reduce or remove a column layout, preventing unwanted blank paragraphs from appearing. Meaningful content is still preserved, and the menu wording is clearer for users converting columns back to regular content.
Original PR description
#### Description of the issue this PR addresses: - When reducing the number of columns or removing a column layout, empty columns were previously unwrapped like any other column. - As a result, columns containing only placeholder paragraphs contributed empty paragraphs to the resulting content, even though they did not contain any meaningful user content. #### Desired behavior after PR is merged: - Fully empty columns are discarded when they are removed. - Non-empty columns continue to be merged as-is, preserving their content. - A single empty paragraph is still kept when all columns are empty to ensure the editor remains editable. - Rename `Remove columns` to `Remove column layout` and update its description to `Convert columns to regular content` to better reflect the operation. task-6296536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283558 Forward-Port-Of: odoo/odoo#270220
Fixes the DIN5008 invoice layout so addresses and information blocks line up correctly when documents are sent by post. This ensures German customer invoices generated for snailmail fit the expected postal layout without changing the normal invoice appearance.
Original PR description
**Steps to reproduce:** - Install l10n_din5008 and Accounting. - Enable Snailmail from Accounting → Settings. - Create a German customer (Fiscal Country: Germany). - Create and post a customer…
**Steps to reproduce:** - Install l10n_din5008 and Accounting. - Enable Snailmail from Accounting → Settings. - Create a German customer (Fiscal Country: Germany). - Create and post a customer invoice using the DIN5008 report layout. - Select Send by Post. - Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters. - Open the generated letter and send it. **Observed behavior:** The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning. **Cause:** The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering. While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks. **Fix:** Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context. Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout. **References** * **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225) * **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869) opw-6387869 Forward-Port-Of: odoo/odoo#285891
The Polish bank account verification process now handles partner records that are missing a VAT number or bank account without crashing. This helps users verify groups of partners more reliably, even when some records still need more information.
Original PR description
When we check for multiple partners with some valid and some being incomplete (no vat or no bank account), a traceback is raised This was due to a bracket accessor, changed into a get in this commit. no-task Forward-Port-Of: odoo/odoo#285631
Mobile invoice line cards now display the line description when no product is selected. This prevents blank cards and makes invoices easier to review and edit on mobile devices.
Original PR description
Invoice lines can be created without a product. However, the mobile kanban view does not handle such lines properly and displays an empty card without a name or image. This commit adapts mobile kanban view to show invoice line's name when `product_id` is not set. Before | After -- | -- <img width="469" height="277" alt="image" src="https://github.com/user-attachments/assets/3b367581-b73d-4b12-a487-1a54c3b88470" /> | <img width="406" height="300" alt="image" src="https://github.com/user-attachments/assets/107d7294-90e8-49c6-826a-9be75c6b799f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285608 Forward-Port-Of: odoo/odoo#284755
The Guatemala electronic invoicing setup now reflects the new tax treatment for regular gasoline containing 10% alcohol. New customer accounting templates will tax only 90% of the gallons, matching the government exemption for the alcohol portion from August 22.
Original PR description
Starting August 22nd Regular Gasoline is changing to a version that contains 10% alcohol. Because of this, the government is only taxing 90% of the gallons since the 10% alcohol portion is exempt. This will update COA for new customers, any current dbs who need to use the new formula can manually update theirs to include the * 0.9 portion. task-6483303 Forward-Port-Of: odoo/enterprise#129483 Forward-Port-Of: odoo/enterprise#129412