Steps to reproduce:
1. Set company warehouse to two-step manufacturing.
2. Create products: X, A, B, C.
3. Add on-hand quantities: A = 10, C = 5.
4. Create a BOM for X with A and B as components.
5. Create and confirm a MO for X in the two-step warehouse.
6. Check product B's forecast report → shows -1.
7. Add a reordering rule for B → forecast shows -1.
8. Edit X’s BOM: remove B and add C instead.
9. Update the MO using the `update_bom` button.
10. Check MO components.
11. Check WH/Preprod transfer → B is still there.
12. Re-check steps 6 and 7.

**Issue**:
In two-step manufacturing, two stock moves are created:
- move1: WH/Stock → WH/Preprod
- move2: WH/Preprod → Virtual/Production

The forecast report uses the company warehouse (WH) as the
location domain and includes move2. It calculates:
  forecast = qty_available - demand = 0 - 1 = -1

The reordering rule uses WH/Stock (its default location) and
includes move1, resulting in the same forecast: -1.

After updating the BOM to remove B:
- move2 is deleted correctly.
- move1 remains on the pre-production transfer.

This causes an inconsistency:
- Forecast report (based on move2) → shows 0
- Reordering rule (based on move1) → still shows -1

We set the product_uom_qty to 0 of the prepoduction moves
so procurement runs with negative qty move and it is merged
with the existing ones in the preproduction picking.
This will make the moves in the preprod picking be 0 and not
deleted to avoid deleting manually added moves from the client
in the preproduction picking.

**Limitation**
The current setup will update the pre_prod_pick moves with
0 demand, but for the post_prod_pick moves there is no pull rule
that will trigger a procurement with -ve old demand to update
the post_prod_pick move leaving it not updated to the bom changes.

This will not be an issue in 18.0+ because of changing to push rules
as the post_prod_pick will not be there unless the MO is done, so
BoM updates will not be needed to be reflected.

opw-4746230

Forward-Port-Of: odoo/odoo#215693
Forward-Port-Of: odoo/odoo#209642

# Context :

By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit batches (default 50) of `mail.mail`
 records while working through the total list of remaining recipients.
See `_action_send_mail_mass_mail` method https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mail/wizard/mail_compose_message.py#L752 In practice, for large mailing lists this will take longer than 15 mins (the default real time limit for CRON jobs) and thus implicitly we expect the worker to time out, re-initiate and continue where it left off.

But since Odoo 18, the new refactor of `ir.cron` tries to penalize jobs that time out too often (>3) and don’t report at least a partial progress
(`_notify_progress()`).
See https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/odoo/addons/base/models/ir_cron.py#L361C1-L367C39

While `_process_mass_mailing_queue` does use the notify progress method (https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mass_mailing/models/mailing.py#L1167),
 it does so at a higher level or granularity (the `mailing.mailing` records in queue).
But it will never called as long as the CRON keeps timing out while
 processing the mails for the remaining recipients (that get committed by batches).
Which leads to the CRON being flagged as timing out to many times, and
 the `nextcall` date of the job being incremented by it’s default value of 1 day.

So in practice:
- mail marketing starts processing
- will time out 3 times after 15 mins (default real time)
- new system kicks in and increments the next execution date + 1 day
- cron does not run until next day (so no new mail batches created) → artificially low sending rate of the campaign even-though everything is in order

# Proposed solution:

One could argue that the real unit of work is the committed mail records
 done in `_action_send_mail_mass_mail`. So we count the processed
 recipients/mails and call _notify_progress()` before the auto commit
 (which will be active when the method is called during the CRON).
This should ensure that the CRON will not be penalized for timing out too
 often as long as the recipients are defacto being processed by batches.

## Changes for 18.3 FW:
replaced the usage of `res_ids_values` with `prepared_mail_values_filtered` to account for variable name changes

opw-4633353

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

Forward-Port-Of: odoo/odoo#200909

<b>Steps to reproduce :</b>

1) Install the Purchase module
2) Create and confirm a Purchase Order with a product and quantity 
3) From the Purchase Order, open the product and archive it

<b>Issue:</b>
Before archiving the product, the `Purchased` smart button correctly displays 
the total purchased quantity.

However, after archiving the product template, this smart button displays `0.0`, 
even though purchases exist.

Additionally, clicking the button opens a blank purchase order line view instead 
of showing related records if the product is archived.

<b>Cause:-</b>
Archiving a product template sets active=False on the template and its variants. 
The computed field `purchased_product_qty` relies on the variants to calculate the total. 
Because the variants are inactive post-archival, the compute method sees no records, 
resulting in a displayed value of 0.0.

Similarly, the smart button action uses the active variants in its domain, 
so it fails to find any related purchase order lines.

<b>Solution:</b>

The context is now explicitly set with active_test=False when computing 
the purchased_product_qty and when generating the domain for the smart button action.

This ensures that even inactive variants are included in the calculation and the view logic, 
preserving the correct purchased quantity and showing the relevant purchase lines after archival.

opw-4781578

Forward-Port-Of: odoo/odoo#213484
Forward-Port-Of: odoo/odoo#209955