Daily updates from Odoo
Wednesday, August 5, 2026
20 changes · master
Resolved issues and error corrections
Automatic bank transaction matching now ignores archived bank accounts when identifying the related customer or vendor. This prevents old or inactive bank details from assigning transactions to the wrong partner, improving reconciliation accuracy.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124748 Forward-Port-Of: odoo/enterprise#124537
This fixes an issue in Studio approval requests where a reference field could be created without a valid related model. Ensuring the reference always points to a defined record type helps prevent approval setup errors and improves reliability for users configuring workflows.
Original PR description
studio.approval.request Many2oneReference must have a valid model field.
The Helpdesk unanswered filter no longer treats automatic acknowledgement emails as customer replies needing attention. This keeps support queues cleaner by showing only tickets that genuinely require a response from the team.
Original PR description
Steps to reproduce: --------- - install website_helpdesk - set an email address on the company partner if it is empty ( it is empty in a database without demo data). - generate a ticket from the website. - apply the Unanswered filter. Issue: ------ system generated acknowledgement message is considered an unanswered customer reply. Fix: -------- system generated acknowledgement messages are now considered answered. task-5138678 Forward-Port-Of: odoo/enterprise#125977
This fixes an issue that blocked companies using Avalara Brazil from confirming several customer invoices at once. Users can now validate multiple affected invoices in one action without the process failing.
Original PR description
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara…
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**. * Select the invoices and click **Action → Confirm Entries**. **_Observed behavior:_** * A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated. **_Cause:_** * During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records. * Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices. **_Fix:_** * Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`. * This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error. opw-6334761 Forward-Port-Of: odoo/enterprise#126437 Forward-Port-Of: odoo/enterprise#124993
The aged payable and receivable drill-down now filters out bills and invoices that were already fully settled for the selected report date. This gives finance teams a cleaner and more accurate view of outstanding balances, especially when reviewing historical aging reports.
Original PR description
Steps to Reproduce: 1. Create a vendor/customer with multiple bills/invoices. 2. Fully pay one or more, leaving at least one still open for the same partner. 3. Open Accounting > Reporting > Partner…
Steps to Reproduce:
1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set to any date and click into an aging bucket for that partner.
Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.
Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.
Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:
action['context'] = {
'recon_limit': options['date']['date_to'],
}
Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.
Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.
opw 6333699
Forward-Port-Of: odoo/enterprise#126021This fix prevents an error that could occur when appraisal survey settings were missing or empty. It helps ensure appraisal survey functionality continues working reliably during setup or upgrade scenarios.
Original PR description
Avoid a TypeError in _compute_allowed_survey_types when allowed_survey_types is False by falling back to an empty list before unpacking and appending the appraisal survey type.
```py
File "/home/odoo/src/enterprise/saas-19.3/hr_appraisal_survey/models/survey_survey.py", line 33, in _compute_allowed_survey_types
survey.allowed_survey_types = [*survey.allowed_survey_types, 'appraisal']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool
```
Ref: https://github.com/odoo/odoo/pull/268125
Bug introduced in: https://github.com/odoo/enterprise/commit/896f54532338b07265722cb4a4161131d408f58c
upg-[4458975](https://upgrade.odoo.com/odoo/request/4458975?debug=1)
Forward-Port-Of: odoo/enterprise#124417Peruvian electronic invoices now format address details according to SUNAT's current UBL 2.1 requirements. This helps prevent validation issues for invoices involving districts and urban subdivisions, supporting smoother legal invoice submission in Peru.
Original PR description
Update electronic invoicing address nodes to align with current SUNAT requirements. This transitions the geographic data formatting from the legacy UBL 2.0 schema to the standard UBL 2.1 specification, ensuring proper structural validation for districts and urban subdivisions. Documentation used: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia+xml+factura+version+2-1+1+0+(2)_0+(2).pdf opw-6282314 Forward-Port-Of: odoo/enterprise#126380 Forward-Port-Of: odoo/enterprise#121390
The Time Off Gantt view now only shows time off types that are currently available for selection. This prevents managers from accidentally choosing outdated or disabled leave types when planning time off.
Original PR description
Steps to reproduce: - In Time Off, create a leave with any selectable time off type - Modify this time off type so that it is not selectable anymore - Go to "Management" -> "Time Off" and select the gantt view - When clicking on a day, the now non selectable time off type still shows in the list of available time off types Reason: When fetching time off types to display, the code did not check if the time off type was selectable, leading to this issue. How it was fixed: Added a condition when fetching time off types to only get those that are selectable. Task ID: 6314831
Planning filters for employees and materials now apply the open-shift rule only to shifts without an assigned resource. This prevents assigned shifts from being incorrectly included or excluded, helping teams view the right planning data.
Original PR description
Before this commit, the domain wrongly assumes that we always search on shifts having no role or a role containing resources of types 'user' or 'material' (1). Additionally to the basic domain which searches on the shifts having resources of types 'user' or 'material' (2). After this commit, we add a condition on domain (1) to only apply it for open shifts (shifts having no resource_id). no-task Forward-Port-Of: odoo/enterprise#126616 Forward-Port-Of: odoo/enterprise#126247
Users can now duplicate several maintenance requests at the same time without the system showing an error. This makes bulk work in the maintenance app smoother and avoids interruptions for teams managing equipment requests.
Original PR description
Currently, when a user attempts to duplicate multiple maintenance requests simultaneously, the system throws a ValueError (Expected singleton). This PR fixes that. ### How to reproduce the issue: - Install `mrp_maintenance` module; - Open maintenance request list view; - Select multiple records and try to duplicate them using the Action button; - It will throw a traceback stating a singleton error. ### Expected behavior after PR is merged: Now multiple maintenance requests will be copied without raising any errors. Forward-Port-Of: odoo/enterprise#124255
The cart now prevents customers from increasing rental product quantities beyond what is available for the selected dates. Availability is also rechecked when rental dates are changed, reducing overbooking risk for planned services.
Original PR description
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning…
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. Add as much product "test" to the cart as possible (the quantity is limited) 7. Open the cart 8. You can increase the amount of the product regardless of its availability Issue: We don't check the renting availabilities to limit the maximum quantity of the product Solution: Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates opw-6274035 Forward-Port-Of: odoo/enterprise#126497 Forward-Port-Of: odoo/enterprise#123056
This fix prevents sale orders linked to point-of-sale planning from receiving duplicate lines when an order syncs multiple times. Sale order lines are now created only once when the POS order is paid, reducing billing and order accuracy issues.
Original PR description
Before this commit, the creation of sale order lines was in sync_from_ui and was executed every time we would enter the method. Since this method is called everytime we sync the order with the backend, it would create duplicated lines on the sale order. The logic is now moved to action_pos_order_paid, which is only called once when the order is paid. Forward-Port-Of: odoo/enterprise#124813
Preparation tickets in Point of Sale now load the required styling again after a receipt printing refactor caused some formatting to disappear. The update also restores missing receipt information, improves receipt display, and ensures customer notes are printed correctly.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395 Forward-Port-Of: odoo/enterprise#124898 Forward-Port-Of: odoo/enterprise#118782
A small issue in the accounting journal report was fixed by cleaning up unused date information in the report line actions. This helps keep the report interface consistent and reduces the chance of confusing or incorrect behavior for users.
Original PR description
Forward-Port-Of: odoo/enterprise#126603 Forward-Port-Of: odoo/enterprise#125266
The manufacturing planning tests were adjusted to match the corrected handling of demand for the current day. This helps ensure replenishment suggestions include same-day activity scheduled later in the day, reducing the risk of misleading planning checks.
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 Forward-Port-Of: odoo/enterprise#126732 Forward-Port-Of: odoo/enterprise#115944
Updated the Italian Balance Sheet report labels to use the correct Italian wording. This helps Italian-speaking accounting users read and interpret the report more accurately without changing the report's calculations or workflow.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Install and switch to italian language 3. Go to Balance Sheets and select Balance Sheet (IT) 4. Some words are not correct [Here]( https://docs.google.com/spreadsheets/d/1-w83oAHTxDRIi-W_VSJiscNclw-yijzQUHOgMnTq7jE/edit?gid=0#gid=0) the wrong fields with their correct translations. opw-6424609 Forward-Port-Of: odoo/enterprise#126253
Users opening a bank statement line from an in-app notification will now see the related conversation and activity panel. This ensures tagged users can view the comment context immediately, reducing confusion during bank reconciliation work.
Original PR description
Problem: When navigating to a bank statement line through a notification, the chatter doesn't appear. Steps to reproduce: 1. Set in app notifications for one of the users 2. Open Accounting > Bank > To Reconcile 3. Select any bank statement line 4. Tag the user from step 1 in a comment 5. Log in as that user 6. Check notifications and click the new notification 7. Notice how the chatter does not appear on the bank statement line after navigating there Cause: The chatter was not enabled on the bank statement line form view. opw-6410186 Forward-Port-Of: odoo/enterprise#125777
Cancelled Mexican electronic invoices can now be reprinted with their required fiscal information, including QR codes, digital stamps, and fiscal folio details. This ensures legally relevant cancelled invoices remain complete and usable for audit or compliance purposes.
Original PR description
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR…
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice. ### Steps to reproduce the issue: 1. Download Accounting and l10n_mx 2. Create an invoice and send it to CFDI 3. Select 'Request for cancel' 4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled 5. Print the invoice again 6. See PDF does not show fiscal information (QR, fiscal folio, etc.) ### Cause of the issue: https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields. ### Reason to introduce the fix: A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled. opw-6393656 Forward-Port-Of: odoo/enterprise#126750 Forward-Port-Of: odoo/enterprise#126466
Date and datetime fields are now hidden from the pivot setup popup once all available time groupings have already been added. This prevents users from accidentally creating duplicate entries and keeps drag-and-drop behavior predictable in spreadsheets.
Original PR description
Current behavior before PR: - Date and datetime fields remained visible even when all their granularities were already added to the pivot. - Users could add the same field with the same granularity multiple times, creating duplicate IDs and causing unexpected drag and drop behavior. Desired behavior after PR is merged: - Hide date and datetime fields from the popup once all available granularities have already been added to the pivot. - This prevents duplicate field IDs and keeps the popup behavior consistent with spreadsheet pivots during drag-and-drop. Task: [6295794](https://www.odoo.com/odoo/project/2328/tasks/6295794) Forward-Port-Of: odoo/enterprise#126830 Forward-Port-Of: odoo/enterprise#123280
Dropdown fields in account reports now show the text cursor aligned to the right instead of appearing in the middle. This improves the visual polish and usability of report filters without changing any business logic or report data.
Original PR description
Dropdown inputs inside of an account report show the cursor in the center of the input field. The cursor has been changed to be right-aligned. task-6247454 Forward-Port-Of: odoo/enterprise#120728