Monday, September 28, 2026
10 changes · saas-19.1
Resolved issues and error corrections
The Sales Analysis report now displays eCommerce category names directly instead of showing only a record count. This makes the optional eCommerce Categories column clearer and more useful for reviewing online sales performance.
Original PR description
Steps to reproduce: - Go to Sales > Reporting > Sales Analysis, switch to list view. - Enable the optional "eCommerce Categories" column. Before this fix: - The column showed a generic "No records"/"1 record"/"N records" count instead of the actual category names, because the many2many field had no widget and fell back to the web client's default x2many column renderer. After this fix: - The column now shows the eCommerce category names as tags via `widget="many2many_tags"`, consistent with how other reports render many2many columns. opw-6580658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289195
This update removes an unnecessary default value from an internal test method parameter. It aligns the code with best practices, reducing the chance of confusing behavior or future maintenance issues without changing user-facing functionality.
Original PR description
[RUF077](https://docs.astral.sh/ruff/rules/method-receiver-default/#method-receiver-default-ruf077) specifies that method receiver parameters, such as `self` and `cls`, should not have default values. The reasoning is because these parameters are usually bound by the method binding protocol, so a default value on a receiver parameter is almost certainly a mistake and can lead to confusing behavior or runtime errors. This method seems to not reference self, and this should not cause errors, but it is best practice to not do this. runbot-[947144](https://runbot.odoo.com/odoo/error/947144) Forward-Port-Of: odoo/odoo#290616
This fix prevents users from opening right-click message actions in the chatter while a new record is still being created. It avoids failed actions such as pinning or copying message links before the related record exists.
Original PR description
**Steps to reproduce:** - Go to Contact app - Create a new record but don't save it - "Creating a new record..." appears in the chatter - Righ-Clicking shows the popup action menu - Trying to pin or create the message link will fail **Issue:** Chatter message actions should be blocked when the record is not created yet. This is not the case for the new right-click popup (see [1]) but it was working for the default `mail.Message.actions`: ```xml t-if="props.hasActions and message.hasActions and !isEditing and !env.inChatter?.disabled" ``` **Fix:** Add the missing `!env.inChatter?.disabled` to `onContextMenu` check before trying to open the message actions (like in [2]). [1] https://github.com/odoo/odoo/commit/ddf2f1711b02456f37d27b17cfc9dc6590b348b5 [2] https://github.com/odoo/odoo/commit/caaa1b97da6a459ecf4a3032110288a6ddf069a1 opw-6592792
This fixes the loyalty program setup so the minimum purchase field is fully hidden for Buy X Get Y promotions. It prevents users from configuring a minimum purchase condition that should not apply to this type of reward, reducing confusion and setup errors.
Original PR description
I think the point was to hide the entire `Minimum Purchase` section when the program type is `buy_x_get_y`, but only the label is hidden. This commit will also hide the div under the label, so no minimum purchase can be set on `buy_x_get_y` programs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288281
This fixes a testing issue in the Bulgarian SAF-T module that caused broad failures when an optional bank account validation component was absent. The change isolates the affected IBAN scenario so normal report tests remain reliable, with no expected impact on real customer use.
Original PR description
Fixes an issue that make most tests fail when the base_iban module is not installed. The BG SAF-T report requires additional information for non-iban bank accounts and thus raises errors when they are not present. If the base_iban module is not installed, the iban verification never happens and an iban account can never be flagged as such. As there is insufficient information on that iban account, it raises validation errors in most other tests. The module is automatically installed when a Bulgarian fiscal localisation is added so the problem will not occur in a real situation. It only affects the tests. To fix the issue in stable, we cannot add the module to the dependencies. The workaround to keep most of the testing logic intact is to isolate the scenario with iban accounts in its own test and skip it if the 'base_iban' module is not installed. runbot-945995 Forward-Port-Of: odoo/enterprise#132587
Fixed a visual issue in Sales quotations where optional product tables could appear lighter than their surrounding area when using dark mode. This keeps the quotation dialog consistent and easier to read for users working with optional products.
Original PR description
**Steps to reproduce:** - Set preferences to dark mode - Create a quotation and add a product with optional products (e.g customizable desk) -> Background of optional products is lighter than the…
**Steps to reproduce:** - Set preferences to dark mode - Create a quotation and add a product with optional products (e.g customizable desk) -> Background of optional products is lighter than the surrounding div **Behavior:** The `div` showcasing optional products is set to be a bit darker to add contrast in the modal. In light mode, table's background is transparent, which allows it to adapt to a darker container. However, this is not the case in dark mode, which causes a mismatch between table and div backgrounds. By default `$table-bg` follows `$body-bg`: https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_variables.scss#L738-L740 And is later set to transparent here: https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/src/scss/bootstrap_overridden_frontend.scss#L74-L75 However when darkmode is enabled, `$body-bg` is re-assigned, which forces `$table-bg` back to the default dark color, bypassing the transparent override. https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_root.scss#L132-L139 --- This commit ensures that `table-bg` is explicitly set to transparent for tables displaying optional products. opw-6569713 Forward-Port-Of: odoo/odoo#288127
KPI reports now ignore archived returns, so hidden or inactive returns no longer appear in business summaries. This keeps reporting dashboards accurate without forcing users to mark returns as completed just to remove them from view.
Original PR description
[FIX] account_reports: KPI provider: properly ignore inactive returns Returns can be archived (setting the 'active' field to False) from the UI, so that the user can hide them when not needed,…
[FIX] account_reports: KPI provider: properly ignore inactive returns Returns can be archived (setting the 'active' field to False) from the UI, so that the user can hide them when not needed, without risking them being regenerated by the cron, and without havin to mark them as completed, which could give misleading information when browsing the history. The problem was here the KPI provider did not properly ignore such returns. ======================================== [FIX] account_reports: make KPI provider test with existing data in db The KPI provider query completely ignores multi-company. Because of that, the test wasn't properly sandboxed, and could fail if any non-test company of the database contained a return made from any untested return type, as it would add one element to the result of get_account_reports_kpi_summary. We now make sure to archive all existing returns, whatever their company, before running the test. Forward-Port-Of: odoo/enterprise#131438
The Bulgarian SAF-T reporting feature will no longer install automatically unless the required advanced accounting setup is present. This prevents the feature from appearing in environments that may not be ready to use it, reducing confusion and setup issues.
Original PR description
As the Bulgarian SAF-T Report is destined for advanced accounting, it should only be available and auto-installed when the 'accountant' module is as well. As the 'accountant' module is not part of the dependencies yet (it is from 20.0 on), we cannot be sure that it is already installed. It is then better to stop the auto installation altogether. Forward-Port-Of: odoo/enterprise#132761
This update removes unnecessary logic from the accounting reports download process. It reduces ambiguity in the code path, helping keep report downloads reliable without changing the expected user experience.
Original PR description
`!something` is never nullish, so `?? true` is dead code. Probably the intention was `if (!(data.no_closing_after_download ?? true))`, but reviewer has the final say and I can change it. Forward-Port-Of: odoo/enterprise#131774
Demo data for Belgian payroll testing is now created using the correct Belgian company context. This prevents errors when loading the demo data through the interface, making setup and testing more reliable.
Original PR description
Before the fix, loading the module's demo data through the UI triggered an error. task-6581013 Forward-Port-Of: odoo/enterprise#132632 Forward-Port-Of: odoo/enterprise#132358