Friday, September 25, 2026
9 changes · master
Resolved issues and error corrections
This fix improves the readability of chat message bubbles in dark mode after a recent visual theme change made blue and green bubbles too dark and hard to tell apart. Reply previews were also refined with clearer borders and smoother styling, making conversations easier to scan.
Original PR description
Dark theme was tweaked with frost, and this negatively affected the message bubble color by making them much darker and undistinguishable between blue and green color. This commit adapt colors to…
Dark theme was tweaked with frost, and this negatively affected the message bubble color by making them much darker and undistinguishable between blue and green color. This commit adapt colors to match not perfectly but very close to the old color as before frost in dark theme. The border are made more visible in dark theme to match the increased overall contrast that frost provides. Reply-to message have their tweaked too: - overall rounder instead of just half of it - background-color is a slightly tinted of the message bubble color and the theme's primary luminance. - border has weight and color matching in all directions, matching the message bubble color <img width="1562" height="1113" alt="Screenshot 2026-09-25 at 00 58 40" src="https://github.com/user-attachments/assets/16836d95-dd5e-4e75-b668-b8bdd6f3ca3b" /> <img width="1555" height="1079" alt="Screenshot 2026-09-25 at 00 58 47" src="https://github.com/user-attachments/assets/7049d8fa-891d-4b8c-a87f-8c3a6a42cbfe" /> Forward-Port-Of: odoo/odoo#290570
Fixed an issue where a selection dropdown could reopen and remain visible after a user picked an option. This improves form usability and helps prevent automated workflow checks from failing due to a stuck dropdown.
Original PR description
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to…
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to close then times out:
FAILED: [8/36] Tour mail_template_dynamic_placeholder_tour
Step Wait for the drop down to disappear
(trigger: div[name="model_id"] .o-autocomplete:not(:has(.ui-autocomplete)))
TIMEOUT step failed to complete within 10000 ms.
This happens because the search filling the dropdown runs 250ms after the last keystroke, so a suggestion of the previous search can be picked while the next search is still scheduled. Picking a suggestion only closes the dropdown. The scheduled search then runs, opens the dropdown on the selected value, and nothing closes it after that.
This commit fixes the issue by discarding the scheduled search when the dropdown closes.
https://runbot.odoo.com/odoo/error/233574
https://runbot.odoo.com/odoo/error/237744
https://runbot.odoo.com/odoo/error/944454
https://runbot.odoo.com/odoo/error/945517
https://runbot.odoo.com/odoo/error/947141
Forward-Port-Of: odoo/odoo#290539
Forward-Port-Of: odoo/odoo#287888This fixes an automated employee event registration test so it opens the expected app menu before running. It helps keep quality checks reliable across Odoo editions and reduces false test failures.
Original PR description
**Trigger:** Running `test_onsite_employee_registration` in a community database starts in Discuss instead of enterprise's usual home menu which crashes the test on the first step. This commit adds the `showAppsMenuItems` util to the test. To ensure the test starts in the correct view. runbot-946289 Forward-Port-Of: odoo/odoo#289486
Fixed an issue where budget amounts in financial reports could lose their proper formatting after a user opened a cell for editing and clicked away without making changes. This keeps displayed figures clear and consistent, reducing confusion when reviewing budgets and profit and loss reports.
Original PR description
Steps to reproduce:- - Create a budget with a P&L report. - Set a value in a cell. - Then press the edit amount, click somewhere else without changing the amount. - The amount is no longer formatted properly. Cause: When user clicks edit, we populate formatted value for locale format type but when user clicks outside without change, in function `onBlur` we compare populated amount(which is formatted) with cell's no format value. So it mismatches and `focused` is never set `false`. Fix: Make getter `editableValue`, which returns `editableNumericValue` for locale format type and no format value otherwise. Now use this `editableValue` in `onFocus`, `onBlur`(this solves the bug) and `inputValue` to make it more clear. [task-6413368](https://www.odoo.com/odoo/project/967/tasks/6413368) Forward-Port-Of: odoo/enterprise#132802 Forward-Port-Of: odoo/enterprise#131989
The signing item popover layout now has better spacing and cleaner styling. This removes a duplicated visual container effect that caused extra borders and shadows, making the signing interface easier to read and more polished.
Original PR description
Prior to this commit, the item popover layout did not have proper spacing between elements, making it look cramped and less visual appealing. The popover also used the popover class twice, resulting…
Prior to this commit, the item popover layout did not have proper spacing between elements, making it look cramped and less visual appealing. The popover also used the popover class twice, resulting in a double border and shadow. This commit adjusts the spacing and popover styling. | Before | After | |--------|--------| | <img width="277" height="198" alt="Screenshot 2026-09-23 at 13 41 09" src="https://github.com/user-attachments/assets/b550932f-b412-4e15-b337-6e3312057cdf" /> | <img width="304" height="221" alt="Screenshot 2026-09-23 at 13 40 09" src="https://github.com/user-attachments/assets/75abd257-0d95-4c82-86c0-910f6dac03e4" /> | | <img width="285" height="65" alt="Screenshot 2026-09-23 at 13 43 00" src="https://github.com/user-attachments/assets/43e1818a-5568-4271-bf48-f6454281280d" /> | <img width="299" height="68" alt="Screenshot 2026-09-23 at 13 43 20" src="https://github.com/user-attachments/assets/6b95fbe3-663e-4d70-b778-ba1f7219a9ab" /> | task-6594820 Forward-Port-Of: odoo/enterprise#132750
German tax report XML exports now correctly include the reporting period when the tax return frequency is set to quarterly. This helps businesses submit complete and accurate quarterly tax filings without manually checking or correcting the exported file.
Original PR description
The `Zeitraum` tag was not set when the tax return periodicity is `quarterly`. The `account_tax_periodicity` field defines `trimester` as the key for the `quarterly` label. In [account_generic_tax_report.py] though, the code compared the periodicity with the `quarterly` label instead of the `key` trimester. **Steps to reproduce**: - Install the `l10n_de_reports` module and switch to the DE Company. - Go to Accounting settings and set `Tax Return Periodicity` to `quarterly`. - Navigate to Accounting > Reporting > Tax Return. - Export the tax report as `XML`. - Open the generated XML file and observe the `Zeitraum` tag. [account_generic_tax_report.py]: https://github.com/odoo/enterprise/blob/338630decbec76580766dd3b38c3241ecfb4c77a/l10n_de_reports/models/account_generic_tax_report.py#L54 Ticket [link](https://www.odoo.com/odoo/project.task/6581536) opw-6581536 Forward-Port-Of: odoo/enterprise#132944 Forward-Port-Of: odoo/enterprise#132593
The Documents portal link now opens in the main browser window when accessed from the website preview. This prevents an error that could interrupt internal users when navigating to Documents from their portal home page.
Original PR description
Steps to reproduce: - Install documents and website - Go to /my/home from the website preview (as an internal user) - Click on the "Documents" portal entry - Go back to /my/home and click on it again…
Steps to reproduce:
- Install documents and website
- Go to /my/home from the website preview (as an internal user)
- Click on the "Documents" portal entry
- Go back to /my/home and click on it again
Issue:
A traceback is raised:
TypeError: Cannot read properties of null (reading 'body')
at WebsiteBuilderClientAction.onIframeLoad
Cause:
The link is opened inside the website preview iframe. For internal users, /my/documents redirects to /odoo/documents, which is served with `X-Frame-Options: DENY`, so the browser blocks it and the iframe's `contentDocument` becomes inaccessible. On the first click, the Chrome workaround in `onIframeLoad` catches the SecurityError and reloads the iframe with `iframe_reload=1`. On the next click, that workaround is skipped because `iframe_reload` is already in the src, and accessing `contentDocument.body` crashes.
Fix:
Register /my/documents in the `isTopWindowURL` registry so that the website preview opens it in the top window instead of the iframe, as done in website_knowledge for knowledge routes.
task-6455756Opening a previously sent Sign template with no fields no longer triggers an access error. The system now avoids adding a placeholder signer when the template is already tied to a sent request, so users can view these templates normally.
Original PR description
Version: 19.0 Steps to reproduce: - Create a sign template with no sign fields - Send a sign request using that template - Open that template from Templates Issue: After a sign request is sent, record rules make the template read only for sign items (create/write only when there are no sign requests). On open, if the template has no signers, the UI auto creates a dummy signer. For an empty sent template, that create is denied by those rules and raises an Access Error. Fix: Guard the auto create signer flow with a sign requests check so that a sent template does not try to create a new signer on open. Task: 6591146 Forward-Port-Of: odoo/enterprise#132898 Forward-Port-Of: odoo/enterprise#132516
Code cleanup and technical improvements
The mail module now registers model fields when records are actually initialized instead of relying on a fixed startup map. This makes later-loaded mail updates visible without rebuilding the store, improving reliability while keeping performance broadly stable.
Original PR description
Before this commit, the store knows every field of every model before a single record exists: makeStore instantiates a throwaway record per model to collect its declarations, then walks the models…
Before this commit, the store knows every field of every model before a single record exists: makeStore instantiates a throwaway record per model to collect its declarations, then walks the models twice, once to pair each relation with its inverse, once to map every field, getter and method an _inherits parent provides to the relation it is read through. The problem is that both maps are fixed at boot: a member a model gains later, from a patch in a lazily loaded bundle, is never seen. This commit registers the fields of a model when its first record runs setup(), pairing a relation with its inverse and with its _inherits parent as each side registers, and resolves an _inherits member on access, ModelInternal.resolveParentField(name): a name this model does not own, neither as a field, a technical key nor a member of its class prototype, and that a parent provides. A positive answer is cached, a negative one is not, as the parent may register the field later. The throwaway record and both loops go. Every read of a record goes through the resolution, so the cheapest answers come first: a model with no _inherits returns on one property read, and a name the model owns on one lookup, both before the cache. Over 200k reads, master against this commit: an own field 122ns / 130ns, an inherited one 1115ns / 1136ns, a technical key 95ns / 98ns. Only a name that is none of those, on a model that does inherit, walks the parent again on every read, 98ns / 305ns; opening a channel of 30 messages resolves 44491 names and walks 80 of them.