## 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

The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed.

The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke
forces the product type to `product` (stockable), triggering reservation logic.

Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with:

`You cannot validate a transfer if no quantities are reserved.`

We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply.

runbot:[108147](https://runbot.odoo.com/odoo/error/108147)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
- Go to a project
- Open the task list view
- Select a task
- In the `Stage` field, attempt to create a new stage

Issue:
- Project users were able to create new task stages from the task list view, despite not having the required permissions.

Cause:
- The `_default_user_id` method assigns the current user as the owner `user_id` of a new stage only when `default_project_id` is not present in the context. As a result, the method returned the current user’s ID, unintentionally making them the owner of the stage. This allowed project users to bypass the intended access rules and create new stages.

Solution:
- Use the `no_create` option for users outside the project manager group to prevent them from creating new stages.
- Updated the `stage_id` field in the task list view to explicitly include `default_project_id` in the context, ensuring proper access control of that stage.

task-4628666

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**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