Friday, July 31, 2026
5 changes · 19.0
Resolved issues and error corrections
This fix prevents the Accounting Journal Report from failing when an invoice contains a tax that was originally a group of taxes but was later changed to a percentage tax. Businesses can continue accessing audit reports reliably after tax configuration changes.
Original PR description
**Steps to reproduce:** - Install account_reports - Create a tax * Tax Computation: Group of Taxes * Definition: [Add a tax] - Create an invoice with that tax - Confirm the invoice - Edit the tax by changing "Tax Computation" to "Percentage" - Go to "Accounting / Reporting / Audit Reports / Journal Report" **Issue:** A KeyError is raised. **Cause:** While generating the data, a group of taxes is found in the journal items. When trying to retrieve its info from the dict listing the groups of taxes, its ID is not found but the system assumes that it's present. opw-6377465 Forward-Port-Of: odoo/enterprise#125291
Users can now click and edit custom fields directly in the Documents list view without first activating another standard field. This makes customizations made through Studio work as expected and reduces extra steps for document management users.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125239
Payroll decimal precision settings will no longer be reset to default values when the payroll module is upgraded. This protects company-specific payroll rounding and rate configurations from being silently overwritten.
Original PR description
decimal.precision records are user-configurable settings that may be adjusted per company needs. With noupdate="0", every module upgrade resets the 'Payroll' and 'Payroll Rate' precision values back to their defaults, silently discarding any customization made by the user. This is inconsistent with the standard pattern used across Odoo modules. For example, the 'quality' module correctly loads its decimal.precision records with noupdate="1". The same convention is followed in core addons such as 'product' and 'account'. The forcecreate="True" attribute already ensures the records are created on fresh installations, so noupdate="1" only prevents overwriting existing values on upgrade — which is the expected behavior for configuration data.
Audit reports now use the company selected for the report instead of defaulting to the user's main company. This ensures accounting report headers show the correct company address when working across multiple companies.
Original PR description
When adding the accounting reports to the audit report, we browse the reports with the request's environment which is defaulting to the user's main company. As a result, the company's address displayed in the reports' header is not correct if we generate the audit report for any other company with a different address. https://github.com/odoo/enterprise/blob/aaab137897e6ad794247470e48d5ea91382577a3/account_reports/data/pdf_export_templates.xml#L85 We propose to inject the correct company in the report's environment. opw-6373956
Manufacturing planning tests were updated to match the latest forecast behavior, which now includes replenishment planned later on the current day. This helps ensure planning suggestions remain reliable when same-day demand is considered.
Original PR description
Updated the forecast suggestion test expectations after monthly demand was updated to count the full current day, so same-day orderpoint replenishment moves scheduled later in the day are also included Community PR: odoo/odoo#262435 TaskID-5490137