Odoo Changelog — 2025-09-25

Thursday, September 25, 2025

6 changes · 17.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] mail: add inactive activity when filtering on date_done

PR #220563

Core17.0mailtest_mailMedium

Fixed activity date filters so completed activities that are kept for history are included in search results. This helps users find records such as CRM opportunities when filtering by an activity's completion date, reducing missing results in day-to-day follow-up and reporting.

Original PR description

## Issue: ## When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain The keep_done option on the…

## Issue: ##
When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain
The keep_done option on the activity_type should be activate to keep old activities
The same issue occured in Activities in the Settings App in Debug Mode, with the Custom Filter on Date Done

## Cause: ##
The domain in the search doesn't include inactive activities
There is a lot of active test in the query

## Fix: ##
When there is `date_done` in the filtered domain in functions `search_fetch()` and `_search()` in `mail_activity_mixin`, we add `active_test=False` to self context
We also do tha same in the `_search()` of `mail_activity` to handle the Settings case

The `search_fetch()` override is needed for App like CRM to make the full query to be executed with the `active_text` context or some informations are lost
If this method doesn't include the context, the lead appeared but the linked Activities aren't fetched completely

## Limitations: ##
Fixing that way can cause to get too many elements, because it will remove all the (active=True) from the all query
This can lead to display inactive or archived leads in CRM, or any archived and inactive data with done activities

## Steps to reproduce: ##
- Open the CRM App
- Go to Configuration > Activity Types
- Select Call
- Toggle Keep Done to enable
- Go in the CRM Pipeline
- Mark any Call activity as Done
- Add a Custom Filter
- Set to Activities > Done Date (keep the default value for today)
- Apply the filter using the Add button
- Before the fix, there is nothing in the filtered pipeline

opw-4744974

#activities#filters#CRM#completed activities

[FIX] helpdesk: order tickets by ticket_ref more intuitively

PR #93058

Enterprise17.0helpdeskMedium

Helpdesk ticket lists now sort ticket references in a way that matches how users expect numbers to be ordered. This makes it easier to find the oldest or newest tickets once ticket counts reach 100 or more.

Original PR description

**Issue**
With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets.

opw-4891916

#helpdesk#ticket sorting#ticket references

[FIX] product: fix product search in po to be case insensitive

PR #228528

Core17.0productMedium

Product searches in purchase order lines now handle product references without being affected by letter casing. This helps users find the right products more reliably and reduces delays or confusion during purchasing.

Original PR description

This commit fixes the issue where products search in PO line was case sensitive.

Before this commit:
Search on `product.product` (which is used in PO lines) was case sensitive if the search term matches exactly the `default_code` or `barcode` because it used exact equal `=` in the search matching.

After this commit:
Search on `product.product` is now case insensitive when matching with `default_code` (using `ilike`) and case sensitive when matching with `barcode` (using `like`).

Task-5080161

#product search#purchase orders#case insensitive

[FIX] l10n_au_reports: no customer payment in TPAR report

PR #95029

Enterprise17.0l10n_au_reportsMedium

Customer payments are no longer incorrectly included in Australia’s Taxable Payments Annual Report gross paid totals. This prevents overstated report amounts and helps businesses produce more accurate TPAR submissions.

Original PR description

Customer payment shoudn't be included in the TPAR report

Steps:

- Unarchive 10% TPAR tax
- Make a bill for a partner X, set 10% TPAR tax on the invoice line and
  confirm
- Create and confirm a customer payment for partner X
- Go to 'Taxable Payments Annual Reports (TPAR)'
-> The column 'Gross Paid' includes the customer payment

Before this commit, we took all line from bank or cash journal to
calculate the gross paid value.

With this commit, we also restrict the lines to include only the one
with 'asset_current' or 'liablility_current' account type.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457)
opw-5045457

#TPAR#Australia#tax reporting#payments

[PERF] mrp: fix redundant phantom BOM calculations

PR #227894

Core17.0mrpMedium

This update avoids repeating the same kit quantity calculations for product variants that share one bill of materials. It can greatly speed up product list loading for businesses with many automatically generated variants, reducing some searches from tens of seconds to around one second.

Original PR description

**Issue -->**

When a kit/phantom BOM is used, quantity calculation for a product is overridden in `_compute_quantities_dict()`. During this override, BOMs are mapped to either `product.product`s, or when none is specified for a BOM, to a parent `product.template` instead. This causes redundant quantity computations in the case where a BOM is mapped to a `product.template` with many variants which all in turn share one BOM record. This can happen when variants configured to be automatically created for product attributes, for example. At scale the redundant quantity computation becomes costly when repeated for every `product.product` under a single `product.template`, when all of them share the same BOM.

**Solution -->**

As quantities are calculated, we can cache the results of the costly `explode()` method in cases where a product's BOM is associated only with a `product.template` record, and not a `product.product`. Due to how BOM kits are identified and mapped by the domain in `_bom_find()`, any product which has been mapped to a BOM record associated only with its parent `product.template` will share an identical quantity calculation. This eliminates unnecessary recalculations for product variants which share the same BOM record.

**Benchmark -->**
`web_search_read` on `product.template` with several records having ~1,000 `product.product` variants 

| Before Fix | After Fix |
|--------|--------|
| ~24-40s | ~1s |

opw-5051773

[FIX] translate: only delete migrated terms

PR #228453

Core17.0toolsMedium

This fix prevents certain existing translations from being deleted during upgrades when they were not previously marked as translated. It helps businesses recover and keep translated field content after moving from older Odoo versions, reducing unexpected English text appearing in multilingual databases.

Original PR description

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you
will notice that some fields that were translated before, are now in
English. This is likely because those translations were not marked as
`state='translated'` in the DB. However, the missing translations were
removed from the `_ir_translation` table during the upgrade.

With this patch, we still keep the conservative behavior of only
auto-translating fields marked as `state='translated'` in the DB (which
is still probably wrong, because user translations should remain the
same; if Odoo was displaying translated text before the upgrade and it
is not after it, that's probably a bug; but that's another story...),
but we no longer delete the other fields. This way, you can still mark
them as translated after the upgrade and use the new tooling provided in
https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc
to recover those translations after the upgrade.

@moduon MT-11570

cc @aj-fuentes

Forward-Port-Of: odoo/odoo#228404

## Issue: ## When using a Custom Filter on Activities > Date Done on any record like in the CRM App, the inactive activities where not included in the search domain The keep_done option on the activity_type should be activate to keep old activities The same issue occured in Activities in the Settings App in Debug Mode, with the Custom Filter on Date Done ## Cause: ## The domain in the search doesn't include inactive activities There is a lot of active test in the query ## Fix: ## When there is `date_done` in the filtered domain in functions `search_fetch()` and `_search()` in `mail_activity_mixin`, we add `active_test=False` to self context We also do tha same in the `_search()` of `mail_activity` to handle the Settings case The `search_fetch()` override is needed for App like CRM to make the full query to be executed with the `active_text` context or some informations are lost If this method doesn't include the context, the lead appeared but the linked Activities aren't fetched completely ## Limitations: ## Fixing that way can cause to get too many elements, because it will remove all the (active=True) from the all query This can lead to display inactive or archived leads in CRM, or any archived and inactive data with done activities ## Steps to reproduce: ## - Open the CRM App - Go to Configuration > Activity Types - Select Call - Toggle Keep Done to enable - Go in the CRM Pipeline - Mark any Call activity as Done - Add a Custom Filter - Set to Activities > Done Date (keep the default value for today) - Apply the filter using the Add button - Before the fix, there is nothing in the filtered pipeline opw-4744974

**Issue** With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets. opw-4891916

This commit fixes the issue where products search in PO line was case sensitive. Before this commit: Search on `product.product` (which is used in PO lines) was case sensitive if the search term matches exactly the `default_code` or `barcode` because it used exact equal `=` in the search matching. After this commit: Search on `product.product` is now case insensitive when matching with `default_code` (using `ilike`) and case sensitive when matching with `barcode` (using `like`). Task-5080161

Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457

**Issue -->** When a kit/phantom BOM is used, quantity calculation for a product is overridden in `_compute_quantities_dict()`. During this override, BOMs are mapped to either `product.product`s, or when none is specified for a BOM, to a parent `product.template` instead. This causes redundant quantity computations in the case where a BOM is mapped to a `product.template` with many variants which all in turn share one BOM record. This can happen when variants configured to be automatically created for product attributes, for example. At scale the redundant quantity computation becomes costly when repeated for every `product.product` under a single `product.template`, when all of them share the same BOM. **Solution -->** As quantities are calculated, we can cache the results of the costly `explode()` method in cases where a product's BOM is associated only with a `product.template` record, and not a `product.product`. Due to how BOM kits are identified and mapped by the domain in `_bom_find()`, any product which has been mapped to a BOM record associated only with its parent `product.template` will share an identical quantity calculation. This eliminates unnecessary recalculations for product variants which share the same BOM record. **Benchmark -->** `web_search_read` on `product.template` with several records having ~1,000 `product.product` variants | Before Fix | After Fix | |--------|--------| | ~24-40s | ~1s | opw-5051773

After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were not marked as `state='translated'` in the DB. However, the missing translations were removed from the `_ir_translation` table during the upgrade. With this patch, we still keep the conservative behavior of only auto-translating fields marked as `state='translated'` in the DB (which is still probably wrong, because user translations should remain the same; if Odoo was displaying translated text before the upgrade and it is not after it, that's probably a bug; but that's another story...), but we no longer delete the other fields. This way, you can still mark them as translated after the upgrade and use the new tooling provided in https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc to recover those translations after the upgrade. @moduon MT-11570 cc @aj-fuentes Forward-Port-Of: odoo/odoo#228404