Current behavior
---
When confirming 1 SO with 2 products with 1 BoM and 1 Rerouting Rule with 0 min/max, with warehouse rule pbm (2 steps: Pick then manufacture), it creates a picking transfer with only 1 MO attached.

Expected behavior
---
The picking transfer should have 2 MO's.

Steps to reproduce
---
1. Create 2 Products with different BoM's, keep per-product routes empty. 
2. Set reordering rules for both to route: Manufacture.
3. Go to warehouses config and set manufacture rule to 2 step (pick -> manufacture)
4. Confirm a SO with those 2 products.

Cause of the issue
---
If we don't have any Make-to-Order routes for a product, the Make-to-Stock default rule of the warehouse would be used. 
In such case, all MO's related to such OP (orderpoint/warehouse) would be linked into one picking. The stock.picking model uses related fields to compute product_ids, which calculates relation using next(...) in the ORM. This takes only the first MO's stock move and ignores the second, hence ignoring other production groups.

Fix
---
Instead of using related fields, use compute to access every relavent production ids.

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

Forward-Port-Of: odoo/odoo#249996

steps to reproduce:
-------------------
1. Install Time Off
2. Go to Configuration > Accrual Plans
3. Create an accrual plan:
   * Set the accrued gain time to "At the start of the accrual period"
   * Set the carry-over time to "At the start of the year"
4. Create a milestone:
   * Set the number of accrued days to 1
   * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0"
5. Go to Management > Allocations
6. Create an allocation:
   * Set the start date to 2025-01-01
   * Set the accrual plan to the one created above
7. Use future allocations to check accruals

current behavior:
-----------------
- On 2026-01-01 --> accrued days = 1  (correct)
- On 2026-02-01 --> accrued days = 1  (should be 2)
- On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) 

cause of the issue:
-------------------
Commit 30c7011 introduced a condition that accrues time off on the carry over date:
https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559

This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped.

**Reason February accruals are skipped:**
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544

* After January, the last_executed_carryover_date is set to 2026-01-01.
* Therefore, February uses last_executed_carryover_date = 2026-01-01.
* The condition evaluates as true for February:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2026-01-01 <= 2026-02-01 <= 2026-02-01
```
As a result, the February accrual is skipped.

**Why it works correctly in March:**
* After February, the last_executed_carryover_date is updated to 2027-01-01.
* March now uses this updated date:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2027-01-01 <= 2026-03-01 <= 2027-02-01
```
The condition is not satisfied, so accruals are processed correctly.

solution:
----------
Add a condition to check if the loop has already run for the current carryover 
period. This ensures the system avoids applying the carryover twice,
allowing subsequent accruals to process as expected.


opw-5020834

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

Forward-Port-Of: odoo/odoo#253409
Forward-Port-Of: odoo/odoo#227646

*: website_sale
Commit [1] added a UI block when doing a reloadable operation, and
unblocked it once the action finished. However, if the action didn't
complete, `ui.unblock` would never be called, leaving the UI blocked
indefinitely.

To reproduce the issue in website_sale:
- Install Website & eCommerce
- Go to /shop page
- Open a product page
- Open the editor
- Click on the main product image
- In the "Images" section > Click on "Add more" in the Extra media field
- Popup shows up but it loads indefinitely

Fix this by always calling `ui.unblock` regardless of the reload
outcome. Also move the media dialog opening to `load`, which runs before
the UI is blocked, passing the selected media as `loadResult` to `apply`.

[1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a
Co-authored by: Robin Lejeune (role) <role@odoo.com>

opw-6003505, opw-6006393, opw-6016898, opw-6013484, opw-6014383

Forward-Port-Of: odoo/odoo#253490
Forward-Port-Of: odoo/odoo#252755

## Issue
When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address* (`purchase.order.dest_address_id`). It is problematic because that field is both readonly and required to confirm the order.

## Steps to reproduce
1. Install *Stock* (`stock`), *Purchase* (`purchase`) and *Sales* (`sale_management`)
2. In Settings, enable *Dropshipping* and *Replenish on Order (MTO)*
3. Create a Product P
    - Set a vendor in the Purchase tab
    - Enable the *Buy*, *Dropship* and *Replenish on Order (MTO)* routes
4. Create a Sales Order
    - Any Customer
    - Product P
    - Confirm the Sales Order
5. Click on the *Purchase* smart button
6. Set the *Delivery To* (`purchase.order.picking_type_id`) field to *"Dropship"*
7. **The _Dropship Address_ (`purchase.order.dest_address_id`) field appears, but it's empty and readonly. The purchase order cannot be confirmed, as the field is required and cannot be updated.**

## Cause
When confirming a Sales Order, the created Purchase Order has a `dest_addres_id` set by `StockRule._prepare_purchase_order`:

https://github.com/odoo/odoo/blob/19.0/addons/purchase_stock/models/stock_rule.py#L350

At that point, the `picking_type_id` of the PO is set to `"Receipts"`, which `default_location_dest_id` is the user's Stock, and the `usage` of that location is set to `"internal"`. When `_compute_dest_address_id` is triggered, it starts by calling the method in `sale_purchase`:

https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/sale_purchase/models/purchase_order.py#L25-L30

Which calls the one in `purchase_stock`:

https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/purchase_stock/models/purchase_order.py#L80-L82

Which sets the `dest_address_id` to `False`. This impacts the rest of first `_compute_dest_address_id`, as the PO does not have a `dest_address_id` anymore, its value will never be updated by the `_compute_dest_address_id` methods.

## Fix
The `dest_address_id` should only be set when dropshipping. The easiest way to do so is to override the `_compute_dest_address_id` in the `stock_dropshipping` module by following a similar logic as in `sale_purchase`:

https://github.com/odoo/odoo/blob/7a39185f83d0daca207c8007512f4700537c7e88/addons/sale_purchase/models/purchase_order.py#L25-L30

opw-5426322

Forward-Port-Of: odoo/odoo#252590
Forward-Port-Of: odoo/odoo#245284

Scenario:

- be on odoo SaaS instance
- be on non-translated page with enough content to do 4 requests
  to /html_editor/generate_text (that are done in chunk of 2000
  characters per request currently)
- open the editor and use "Translate to {lang}" (ai translation)

Result: you see a message "Connection lost. Trying to reconnect..." and
after waiting 10-20 seconds, no translation are inserted in the page.
In reality the requests after the 3 first ones were cancelled (with
error 429 too many requests) by nginx, and the 3 first ones worked
correctly but their result was not used because of the error of the
other ones.

Fix:

- decrease the number of concurrent request from 5 to 3 which is the
  current default for this route on SaaS

- adapt the code so if there is errors on one request, successfull
  requests will still be applied with the text "Translation Error.
  {number} text blocks were skipped during translation. Please try
  again." for the blocks that were missed.

This way even if there is an error, the translation is not totally
blocked and doesn't need to be restarted from zero (making it impossible
in the original scenario).

Side note: the number of text blocks not translated was a multiplication
of the total number of text blocks by the number of failed response.
This fix adapts it to just the total of words substrating the number of
translation applied.

opw-5892402

Forward-Port-Of: odoo/odoo#253683
Forward-Port-Of: odoo/odoo#250611

When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied

Steps to reproduce:
1. Install Sales app and l10n_cl and loyalty module
2. Switch to CL Company
3. Go to Sales > Products > Discount & Loyalty
4. Create a new program and change the rule's minimum purchase to 0.00
5. Go to Sales and create a new quotation for customer Acme Corporation and add any product
6. Change the sale order line unit price to 0.4 and click on Reward
7. No discount is applied

Problem:
The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency.

Solution:
Pass the order currency when computing the discountable amount

opw-5946975

Forward-Port-Of: odoo/odoo#252756
Forward-Port-Of: odoo/odoo#250153