Monday, September 28, 2026
9 changes · saas-19.2
Resolved issues and error corrections
The Indian payroll payment report now shows the payment date when the ENET payment option is selected. This helps payroll users review and process payment information consistently without missing a required date field.
Original PR description
Bug reproduction - Install l10n_in_hr_payroll, payslips, validate, pay, Payment Date is not there if you select enet option Bug cause - It is made invisible if the option is enet before Bug solution - Remove the block that made it invisible task-6584795
Shared project users with editing rights can now create tasks without running into a customer access error. The customer field is correctly protected from edits when users are not allowed to change it, preventing task creation from failing.
Original PR description
Steps to Reproduce: - Install Project. - Share a project with a project sharing user having Edit or Edit with limited access permissions. - Log in as that shared user. - Open the shared project and create a task from the list or kanban view. - Observe that creating the task fails with an AccessError on Contact. Issue - Creating the task fails with an AccessError on the Customer (`partner_id`). Cause - The customer field is editable for project sharing users who should not be allowed to modify it. As a result, `partner_id` is included during task creation and triggers an access error. Solution - Correct the readonly condition on the customer field so unauthorized users cannot modify it. task-5075150 Forward-Port-Of: odoo/enterprise#123052
This change removes an inappropriate default value from an internal method parameter in Odoo's core test framework. It follows best-practice checks to reduce the risk of confusing behavior or runtime errors during automated testing, with no expected impact on regular users.
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 fixes the loyalty promotion setup so minimum purchase details are fully hidden for buy X, get Y programs. It prevents users from accidentally setting a minimum purchase rule that does not apply to that promotion type.
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 visual issue in Sales quotations where optional product tables appeared with a mismatched background in dark mode. The optional products area now blends correctly with its surrounding panel, improving readability and visual consistency 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
KPI summaries now ignore archived returns, so hidden or inactive returns do not appear as pending or distort reporting history. Related tests were adjusted to stay reliable even when other companies already have return data in the database.
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 be installed automatically in this version. This prevents it from appearing in environments that may not have the advanced accounting capabilities it depends on, 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 change removes unnecessary fallback logic in the account reports download flow. It keeps the behavior clearer and easier to maintain without changing the user-facing reporting 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-related modules now loads using the correct Belgian company context. This prevents an error when users install or load the demo data through the interface, improving setup reliability.
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