Sunday, October 12, 2025
5 changes · saas-18.3
Resolved issues and error corrections
The invoice payment button now points to the payment that is actually confirmed and reconciled, instead of an older draft payment in certain duplicate-payment workflows. This helps accounting users avoid confusion and reduces the risk of reviewing or acting on the wrong payment record.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/odoo#202076
Invoices now open the currently reconciled payment instead of an older draft duplicate when payments are reset, duplicated, and reconciled. This prevents users from being sent to the wrong payment record and helps keep invoice payment tracking accurate.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/enterprise#89089
Hierarchy views now better handle circular reporting relationships, such as an employee accidentally set as their own manager. This prevents crashes and endless loading loops, improving reliability for users viewing organization charts and other hierarchical data.
Original PR description
This commit fixes some traceback errors in the web_hierarchy module by refining the cycle detection of records in hierarchies. Infinite loops in case of a cycle's presence in the `removeChildNodes` and `processNode` methods are now prevented. Additionally, tree re-rooting in case of the presence of two nodes in the same tree, which implies a cycle's existence, is now avoided. There was an edge case where an employee could be their own manager, creating two child nodes of that employee. The case is now handled by making sure that records are unique for each parent ID in the `recordsPerParentId` object. task-5022670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231040 Forward-Port-Of: odoo/odoo#228976
Indian GST return processing now looks for a valid purchase journal across all companies in a tax unit, rather than only the main company. This prevents record creation failures when the main company lacks a purchase journal but another company in the tax unit has one configured.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. OPW: 5159518 Forward-Port-Of: odoo/enterprise#96838
This fixes a display issue in Barcode where guidance text could appear as raw HTML after validating a filtered transfer. Users now see the intended readable help message, reducing confusion during warehouse operations.
Original PR description
Issue: ------ When validating a transfer after filtering by scanning a product, the empty help message was shown as raw HTML instead of parsed text. Steps to reproduce: ------------------- 1. Install Barcode. 2. In Inventory, create a receipt with product Pedal Bin. 3. Click Mark as Todo. 4. Open Barcode → Operations → Receipts. 5. Scan the barcode of Pedal Bin. 6. Open the receipt and validate. The helper text is displayed in raw format. Cause: ------ The server returned the help text as a plain HTML string. Since JSON serialization strips Python markup objects, the client received raw HTML, which was not parsed and therefore rendered as-is. Fix: ---- The web client now wraps the help text with `markup()` before display, ensuring the message is parsed and shown in a readable format. opw-5090075 Forward-Port-Of: odoo/enterprise#96655 Forward-Port-Of: odoo/enterprise#95020