Daily updates from Odoo
Thursday, July 30, 2026
5 changes · 17.0
Resolved issues and error corrections
The aged payable and receivable report drill-downs now show only items that still have an outstanding balance. This prevents already paid invoices, bills, payments, or write-offs from appearing in the details, making the report easier to trust and reconcile.
Original PR description
Steps to Reproduce: 1. Create a partner (vendor or customer) with multiple bills/invoices, respectively. 2. Fully pay one or more, leaving at least one for the same partner still open. 3. Open…
Steps to Reproduce: 1. Create a partner (vendor or customer) with multiple bills/invoices, respectively. 2. Fully pay one or more, leaving at least one for the same partner still open. 3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable. 4. Click into the total aging bucket cell for that partner. Issue: The drill-down list shows bills/invoices that are already fully settled (`amount_residual = 0.00`) alongside those that are genuinely outstanding. Affects both Aged Payable and Aged Receivable, since both share the same underlying method. Only appears when the partner has at least one open balance; if everything is paid, there's no bucket to drill into, so the bug doesn't surface. Root Cause: Bucket totals (`_aged_partner_report_custom_engine_common`) correctly recalculate each line's residual from `account_partial_reconcile` and exclude zero-residual lines via a `HAVING` clause. The drill-down list, however, is built separately by `aged_partner_balance_audit`, whose domain only filters by reconcile flag, journal type, and date range - it never checks amount_residual, so every line in that window gets listed regardless of payment status. Fix: Added (`'amount_residual', '!=', 0`) to the domain in aged_partner_balance_audit. Since this method is shared by both reports (differentiated only by `journal_type`), one fix covers both. Result: Both drill-downs now correctly exclude settled bills, invoices, payments, and write-offs, showing only genuinely outstanding items. opw : 6333699
This fix prevents worksheet report generation from failing when a chatter section is added through Studio. Chatter-related fields are now ignored when building the printable report, so users can save and print worksheet templates reliably.
Original PR description
Steps to reproduce: - Enable Studio - Create a worksheet template - Design the template in Studio - Add a Chatter on the form view - Save Issue: Adding a chatter to a worksheet template's model crashes the report generation. `_get_qweb_arch` builds the set of fields to display in the printed report directly from the form view's fields, without excluding the ones living inside the `oe_chatter` div (message_ids, message_follower_ids, activity_ids). Those fields then end up with a t-field in the generated qweb template, which crashes when rendered since they aren't meant to be displayed outside of the chatter widget. To fix this we xclude fields that are descendants of the `oe_chatter` div when collecting the form view's fields, the same way `mail`'s `_postprocess_tag_field` already skips them for regular form view postprocessing. This is already fixed in 18.0 thanks to https://github.com/odoo/odoo/pull/156463 and https://github.com/odoo/enterprise/pull/58055 opw-6397700
Accounting users in Spanish companies can now export VAT record books that include Point of Sale transactions without needing Point of Sale access. The report safely reads the required POS data internally, preventing access errors and keeping tax reporting workflows uninterrupted.
Original PR description
Steps to reproduce:
- With an ES Company
- Open a POS session, add product with tax and pay
- As a user with only accounting access
- Go to Accouting > Reporting > Tax report
- Select Generic Tax report
- Print "VAT record Books"
Issue:
An AccessError will raise
```
Access Error
You are not allowed to access 'Point of Sale Session' (pos.session) records.
This operation is allowed for the following groups:
- Point of Sale/User
Contact your administrator to request access if necessary.
```
Analysis:
Vat Record Books handler for POS needs to read pos.session and pos.order records. Currently, the action is performed with the rights of the user running the report, so accounting-only user face an error.
As POS records are only read internally to build the report, we add sudo call to get the data.
opw-5862529This fixes an issue where work orders in the Shop Floor view could appear in an inconsistent order after refreshing or changing filters. The view now preserves the intended order based on work order status and scheduled start date, helping production teams see tasks reliably.
Original PR description
Records already in cache are intended to be sorted by their position in `recordCacheIds` to preserve the previously computed display order. However, `recordCacheIds` stores database record ids (`resId`), and currently the cache lookup incorrectly uses `id` instead. As a result, every lookup returns `-1`, and could lead to inconsistent ordering. Steps to reproduce: 1. Create several manufacturing orders with work orders assigned to the same work center. 2. Give the work orders different states and scheduled start dates. 3. Open Shop Floor and display that work center. 4. Refresh the view or change a filter so the records are recomputed. It should use `resId` so the previously computed display order remains, which is based on state and scheduled start date. Related: odoo/enterprise#74421 opw-6402233
Quality team email aliases now keep the correct company assigned, even when the company field is hidden or left blank. This ensures incoming emails can create quality tickets consistently in single-company and multi-company setups.
Original PR description
Issue Before This Commit: ---------------------------------- In a single-company environment, the quality team email alias was created without a company ID. As a result, incoming emails could not…
Issue Before This Commit: ---------------------------------- In a single-company environment, the quality team email alias was created without a company ID. As a result, incoming emails could not generate quality tickets, making the email alias ineffective. Steps to produce: ---------------------------------- - Install `quality_control` in a single-company environment. - Create a quality team with a name and an email alias. - Navigate to Settings → Technical → Aliases and check the newly created alias. - The Company ID is False, preventing the creation of new tickets via email. Cause ---------------------------------- In a single-company environment, the company_id field is not visible, is not required, and has no default value, so it is never set. The same issue can also occur in a multi-company environment when the user explicitly creates a team without selecting a company. After this Commit: ---------------------------------- The company_id is now set in the alias default values based on the quality team’s company. It is also updated whenever the team’s company changes, ensuring consistency and allowing incoming emails to reliably create quality tickets in all environments. Task ID: 4595798