Monday, September 28, 2026
10 changes · saas-19.4
Resolved issues and error corrections
US accounting templates now use "Depreciation" for tangible asset accounts where "Amortization" was incorrectly used. A separate amortization account was added for intangible assets, helping businesses classify asset expenses more accurately.
Original PR description
Amortization is used when it is an intangible asset (loan/ goodwill/ IP). Depreciation would be used for a physical tangible asset (vehicles/ PPE). This commit renames some accounts wrongly using the "Amortization" wording when "Depreciation" should've been used. We also add a new account that can be used for Amortization. task-6578876 Forward-Port-Of: odoo/odoo#289595
This update fixes several issues in Odoo's automated web testing tools and test data validation. It helps developers catch mistakes earlier and reduces false or confusing test results, improving the reliability of future updates across affected apps.
Original PR description
- https://github.com/odoo/enterprise/pull/131914 Various Hoot/web tests fixes. See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#290553 Forward-Port-Of: odoo/odoo#256814
A small issue in Odoo's core test code was corrected to follow best-practice coding rules. This reduces the chance of confusing behavior in internal tests and helps keep automated quality checks passing.
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 update corrects how internal test data fields are defined and validated across several Odoo Enterprise apps. It helps catch invalid test data earlier, making automated tests more reliable and reducing the risk of hidden issues reaching users.
Original PR description
- https://github.com/odoo/odoo/pull/256814 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#132937 Forward-Port-Of: odoo/enterprise#131914
Fixed a small issue in the web interface status bar that could prevent it from referencing page elements correctly. This improves reliability for users interacting with status-based fields without changing business workflows.
Original PR description
`rootRef` is an OWL `useRef`, so access its element through `.el`. The previous code incorrectly treated it as a `Signal.ref`.
This update removes unnecessary logic from the accounting reports download process. It helps keep the report download code clearer and reduces the chance of confusion in future maintenance, with no expected change for everyday users.
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
This fixes a visual issue in sales quotations where optional product tables appeared lighter than their surrounding area when dark mode was enabled. The change keeps the optional products section visually consistent, improving readability and polish for users working in dark mode.
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
The loyalty program form now fully hides the minimum purchase section for Buy X Get Y promotions. This prevents staff from setting purchase requirements that should not apply to this promotion type, reducing configuration mistakes.
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
The Bulgarian SAF-T reporting module will no longer be installed automatically unless the required advanced accounting capabilities are present. This prevents businesses from seeing or enabling a specialized compliance report in setups that may not fully support it.
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
KPI summaries now correctly exclude archived returns, so hidden or inactive returns do not appear in reporting indicators. This prevents misleading compliance or accounting status information while keeping tests reliable across databases with existing company data.
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