Steps to reproduce:
-------------------------------------
1. Install the Subscription module.
2. Go to Subscription > Configuration > Recurring Plans.
  * Open a Monthly recurring plan and enable Align to Period Start.
3. Create a new Subscription:
  * Select the configured monthly plan.
  * Add any subscription product.
  * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025).
4. Confirm the subscription.
5. Create a draft invoice.

Observation:
-----------------------------------
In the invoice line, you see the message:
`61 days 11/01/2025 to 12/31/2025`

It should be:
`1 Month 11/01/2025 to 11/30/2025`

Issue:
-----------------------------------
https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range

Solution:
-----------------------------------
Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled

For upsell orders, the fix is NOT applied because for upsells, `new_period_stop`
is already set to the parent subscription's `next_invoice_date`, which
represents the correct billing boundary.

opw-5920036

Forward-Port-Of: odoo/enterprise#107407

Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
    * Employees: No
    * Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position

Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.

Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights

Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges

opw-5969416

Forward-Port-Of: odoo/odoo#252209

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#258986
Forward-Port-Of: odoo/odoo#249306

**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#257517
Forward-Port-Of: odoo/odoo#250904

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

Steps to reproduce:
-------------------------------------
1. Install the Subscription module.
2. Go to Subscription > Configuration > Recurring Plans.
  * Open a Monthly recurring plan and enable Align to Period Start.
3. Create a new Subscription:
  * Select the configured monthly plan.
  * Add any subscription product.
  * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025).
4. Confirm the subscription.
5. Create a draft invoice.

Observation:
-----------------------------------
In the invoice line, you see the message:
`61 days 11/01/2025 to 12/31/2025`

It should be:
`1 Month 11/01/2025 to 11/30/2025`

Issue:
-----------------------------------
https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range

Solution:
-----------------------------------
Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled

For upsell orders, the fix is NOT applied because for upsells, `new_period_stop`
is already set to the parent subscription's `next_invoice_date`, which
represents the correct billing boundary.

opw-5920036

Forward-Port-Of: odoo/enterprise#107407

Cause:
======
Because the debounce function is called with await, the execution of
`debouncedSCSSColorsCusto` pauses for every mousemove event.
This prevents subsequent calls from overlapping, meaning the debounce
logic never triggers to cancel previous timers. This results in the
heavy SCSS generation running sequentially for every single mouse
movement, causing performance lag.

In other words, the await forced the browser to handle one request at
a time, completely finishing it before accepting the next one.

Solution:
==========
In the gradient picker, only update the visual CSS gradient preview
during drag and defer the `onGradientChange` callback to mouseup to
avoid triggering heavy operations (e.g. SCSS generation) on every
mousemove.

Steps to reproduce:
===================
1. Go to website & edit mode.
2. Click on Header block.
3. Click on background color preview & select Gradient & Custom.
4. Click and drag the Angle knob.
=> The website preview triggers excessive updates dragging the knob

opw-5411628

Forward-Port-Of: odoo/odoo#241764

## Context
On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it.

## Issue
When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size.

## Steps to reproduce
1. Install the *eCommerce* (`website_sale`) app.
2. Create a product and set a picture for it.
3. Go to that product's page in the Website app and open the website editor.
4. Click on the picture and replace it.
5. **The options to transform the picture are not displayed.**

## Cause
The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16

## Solution
We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173

We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo.

On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are:
- Description
- Tooltip
- Transform (*"Transform the picture"*)
- Size

## Tests
The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it.

https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16

## Options displayed
|   | Before this commit  | After this commit  | Previous versions |
|---|---|---|---|
|  **Before replacing the image**  | Media, Re-order | Media, Re-order  | Media, Re-order
|  **After replacing the image**  | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality


opw-5251864

Forward-Port-Of: odoo/odoo#247539
Forward-Port-Of: odoo/odoo#241071

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

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

Forward-Port-Of: odoo/odoo#259257
Forward-Port-Of: odoo/odoo#250294

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
    * Employees: No
    * Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position

Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.

Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights

Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges

opw-5969416

Forward-Port-Of: odoo/odoo#252209

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#258986
Forward-Port-Of: odoo/odoo#249306

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either.

E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68).

So here, we skip the update of relations to accounts on tax groups, if the account already exists.

Forward-Port-Of: odoo/odoo#259160

**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#257517
Forward-Port-Of: odoo/odoo#250904

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#101714
Forward-Port-Of: odoo/enterprise#98571

**Steps to reproduce:**
- Install Documents app
- As admin, share a folder to a portal user with editor access
- Log as portal user on mobile view
- Try to upload a new file from the control panel
- File dialog appears, but selected file is not saved

**Issue:**
Seems like changing the boostraps dropdown to the owl component created this issue. It is caused by Upload button trying to use the `<input>` of its parent dropdown. When the dialog opens, the current dropdown and its parent are removed (with the surrounding overlay) due to the default closingMode.
`onSelected="() => this.uploadFileInputRef.el.click()"`

Also the page has multiple time the same `<input>` element due to the duplication of the actions for the bottom drawer.

**Fix:**
Put the `<input>` element in a place where it won't be duplicated on mobile when creating the overlay with the upload interactions. This ensures we always use the same `<input>` element for the dropdown, so that files are properly added even if the dropdown is removed.

We could also change the closingMode to `closest` or `none` and manually close the remaining dropdown(s) on file upload.

dropdown component: https://github.com/odoo/enterprise/commit/06802d3d6cc5141842adba74f7c9f1970feeb263
similar issue for non-portal user: https://github.com/odoo/odoo/commit/8a871a120b75f7c09c70dbf07530239244dbb5d6

opw-6042353

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