**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Currently, when the user takes a component product from different lots for manufacturing, after producing the product, the stock moves are modified in such a way that only the first lot is used for consumption, ignoring the intended selection across multiple lots.

## Steps to replicate:
- Install mrp without demo data
- Enable Lots and Serial Numbers
- Create two products: Car and Bolt, and set Bolt to be tracked by lots
- Update the on-hand quantity of Bolt by creating two lots with 10 units each
- Create a BoM for Car with Bolt as a component and quantity set to 4
- Create and confirm a Manufacturing Order for Car, see Components and open More Details
- Assign Lot 1 with quantity 2 and Lot 2 with quantity 2, then save the MO
- Click on Produce All

## Observed Behavior:
Even though the user manually selected 2 units from lot 2 and 2 units from lot 1 , after producing the product, all 4 units are taken from lot 1 instead of being split evenly. This can also be verified in the traceability report.

## Root cause:
This issue was introduced after commit [1], which added support for considering physical inventory (stock quants) when updating quantities on stock moves and automatically creating or adjusting stock move lines.

When the `Produce All` button is pressed, the `button_mark_done` method is triggered This calls `pre_button_mark_done`, which in turn invokes `_set_quantities` [2]. That method calls `_set_qty_producing`, eventually leading to `_set_quantity_done`  [3], which marks the move as done. During this process, `_set_quantity_done_prepare_vals` is executed.

Inside `_set_quantity_done_prepare_vals` [4], the system assigns quantities to move lines based on the move and its reservations. In this scenario, the stock move has a total quantity of 4. The first move line has a quantity of 2, which is subtracted as the consumed (taken) quantity.

At this point, the reserved (available) quantity is also 2, so the final condition is satisfied. This condition subtracts the available quantity from the remaining required quantity for the move, which is 2 for the next move line. As a result, the remaining required quantity becomes 0.

Because of this, the next move line ends up with a required quantity of 0 and is removed at [5], effectively prioritizing the first move line.

[1]:
https://github.com/odoo/odoo/commit/eed96007f9032d1a9e30211c8bdcf53f8ce96a49 
[2]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/mrp/models/mrp_production.py#L2821-L2830 [3]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/mrp/models/mrp_production.py#L1342-L1343 [4]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/stock/models/stock_move.py#L2301-L2322 [5]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/stock/models/stock_move.py#L2286-L2288
## Solution:
Since manual selection of lots is possible, the total available quantity across all lots should be checked before prioritizing any specific move line for updates.

Updates should only occur when lots are not being used and the maximum possible quantity has already been reserved from the total available inventory.

This prevents all quantities from being assigned to the first stock move line associated with a lot and ensures manually added lots remain on the move lines.



opw-6058908

### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.

### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.

### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account

To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.

### Before
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td style="{color: red}">Stock input</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

### After
(Or normal behavior without inter-company transfer)
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td>Stock output</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

opw-5993147

**Issue:**
When a user posts a credit note with a currency exchange difference relative to the reversed move,
the resulting exchange move lines lack the mandatory analytic distribution.
This triggers a validation error, preventing the credit note from being posted.

**Steps to reproduce:**
- Set "mandatory" applicability on any analytic plan.
- Set two different currency rates on two different dates for any foreign currency.
- Create and post an invoice on the first date (ensure the mandatory analytic distribution is set).
- Create a credit note from that invoice using the second date.
- Click on the post button on the credit note.

Result: A validation error occurs even though the credit note itself has the mandatory analytic plan set,
because the auto-generated exchange move does not.

**Fix:**
Since the context key validate_analytic is set to True by the post button action,
it must be manually set to False during the automatic creation of exchange difference moves to bypass the mandatory plan check.

OPW-6081632

Forward-Port-Of: odoo/odoo#259381

Steps to reproduce:
-------------------
1. Install Time Off.
2. Create a user and employee without Time Off access rights.
3. Create another employee and set the first employee as the manager.
(This automatically sets them as the Time Off approver.)
4. Create a time off request for the second employee from Time Off > Management.
5. Ensure that "Employee's Manager" is set as the approver in the corresponding Time Off type.
6. Log in with the first user, go to Overview and try to approve the leave.

Issue:
------
An AccessError occurs when approving the leave from the overview:

```python
You do not have enough rights to access the fields 'leave_id'
on Time Off Calendar (hr.leave.report.calendar)
```

Cause:
------
In `hr_leave_report_calendar`, the `leave_id` field is restricted to `hr_holidays.group_hr_holidays_user`.
When a leave manager without Time Off user rights tries to approve a leave from the overview,
the field access restriction triggers an AccessError.

related commit: https://github.com/odoo/odoo/commit/b5c9420543bdaae52b191e518c5e0f31ba925e46

Solution:
---------
Remove the group restriction on the `leave_id` field and introduce record rules
on `hr.leave.report.calendar` to control access.

- Leave managers can read records related to their employees.
- Time Off officers retain full read access.

This prevents the AccessError while still restricting the visibility of leave information for unauthorized users.

opw-5921263



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

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#250904