__
Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 
__
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

Nothing happens

When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546

The company isn't taken into account in the domain, applying the holiday for every company.
 __
opw-5222883

Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#238917

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

This commit is a backport of https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823 and https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424.

## Issue
When renewing a subscription, the tags and followers are not copied from the original subscription to the new one.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a confirm a subscription S
    - Any *Customer*
    - Any *Recurring Plan*
    - Any Product
    - In the *Other Info* tab, add a tag T
3. There should be two followers on the subscription S: the creator of the subscription, and the customer. If it is not the case, add at least one follower.
3. Create and confirm an invoice for subscription S
4. Back on the subscription S, click *Renew*
5. **The tag T is missing on the new subscription. Also, the followers were not copied from subscription S.**

## Cause & Fix

### Tags
In `SaleOrder._prepare_upsell_renew_order_values`, tags are not part of the `values` generated when renewing a subscription:

https://github.com/odoo/enterprise/blob/a650fb74fd79965a6f0e441e61d8977c599057e6/sale_subscription/models/sale_order.py#L1149-L1171

They were added by https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823:

https://github.com/odoo/enterprise/blob/245759ef82250a8eb32f38853e5c5f6aac841823/sale_subscription/models/sale_order.py#L1173-L1175

### Followers
Similarly to the tags, followers were not added/subscribed to the subscription when generating the renewed subscription. This was fixed by https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424, by creating and calling the `_subscribe_followers_to_new_order(order)` after creating the new subscription (`order`):

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L956-L958

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L2147-L2157

opw-5478071