Steps to reproduce:
- Apply a theme on a website, for example Bistro
- Enter website edit mode and open the Theme tab
- Click Switch Theme
- Hover the card of Bistro (the theme currently in use)
- "Use this theme" button appears like every other card
- It should show "Update theme" and "Remove theme" instead

Since [1], `self.env.website` only reads `website_id` from the context, and that key is stripped on a non-website route, where the resolved website is moved to `host_id` instead. The theme kanban is read through a plain ORM call, so `_compute_is_installed_on_current_website` resolved no website and no card was ever flagged as the one in use.

This commit falls back on `host_id` to resolve the current website. `button_refresh_theme` and `button_remove_theme` get the same fallback: they resolved the website the same way and acted on an empty one, which went unnoticed only because the buttons triggering them were never displayed.

task-6575727

[1]: https://github.com/odoo/odoo/commit/9d97e0e919a953e4f86e42e32ca24d9790840f68

Forward-Port-Of: odoo/odoo#288383

When a tax affects the base of the subsequent ones — `include_base_amount`,
which is how the ISC is set up in Peru — Odoo links the tax line it generates
to those subsequent taxes, so the ISC tax line ends up carrying the IGV in its
`tax_ids`.

The PLE ledgers build their base columns by summing every move line related to
a given tax group, so that ISC tax line was added to `base_igv` as well and the
ISC ended up reported twice: once inside the taxable base and once in its own
column. A line of 1000.00 with 100.00 of ISC and 198.00 of IGV was declared
with a base of 1100.00 instead of 1000.00.

`l10n_pe_edi` already subtracts the ISC from the `cbc:TaxableAmount` of the CPE
sent to SUNAT, so the electronic invoice and the ledger disagreed on the very
same document.

### What changed

The base taxes are now joined only for base lines, instead of repeating the
condition on each of the twelve `base_*` columns. Besides keeping tax lines out
of the base columns, this also stops a tax line from being counted once per
subsequent tax: an ISC followed by both the IGV and the ICBPER produced two rows
in the join, and its own column was reported twice.

### Scope

`_get_ple_report_data` is shared, so this covers the sales ledger 14.1 and the
purchase ledgers 8.1 and 8.2. A configuration where no tax affects the base of
a later one is unaffected: the standard Peruvian chart template has no purchase
ISC, so ordinary IGV-only purchases report exactly the same values as before.

### Tests

- `test_sale_report_isc_base`: an ISC preceding the IGV, on an invoice and on a
  credit note; the base column excludes the ISC.
- `test_sale_report_isc_reported_once`: an ISC followed by the IGV and the
  ICBPER is reported once.

Both fail without the fix.

Supersedes odoo/enterprise#128300, which targeted 19.0.

Forward-Port-Of: odoo/enterprise#132106
Forward-Port-Of: odoo/enterprise#131475

Currently, when the user tries to produce a Manufacturing Order after generating a lot and increasing the quantity, they get a user error stating that a lot must be assigned.

## Steps to produce:
- Install Manufacturing
- Go to the setting enable Lots & Serial Numbers and Storage Locations
- Create a product 'Soda can' which is tracked by lots
- Create a bill of material for Soda can with component as 'Metal sheet'
- Create a storage location called 'Fridge' with parent location WH/Stock
- Create a Putaway rule for the Soda can to be stored in the fridge when it arrives in WH/Stock.
- Create and confirm a Manufacturing Order for soda can
- Click 'Generate Lot'
- Increase the total quantity to be produced from 1 -> 2
- Click 'Produce All'

## Observed Behaviour:
```
Invalid Operation:
You need to supply a Lot/Serial Number for product:
- Soda can
```
## Root cause:
When the user confirms the Manufacturing Order, `_apply_putaway_strategy` is called through:
``action_confirm -> _action_assign -> _apply_putaway_strategy``

This happens for both finished-product move lines and component-product move lines.

It updates the finished product move lines' destination location to `WH/Stock/Fridge` at:
https://github.com/odoo/odoo/blob/fd06c4df5889e23cfb701c12d743b5652141a111/addons/stock/models/stock_move_line.py#L288-L292

However, the `move_finished_ids` destination location remains` WH/Stock`.

After the user generates a lot and increases the production quantity using the wizard, `change_prod_qty()` updates the finished move's demand and re-reserves it through `_update_finished_moves()`:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L77

This calls `_action_assign` on the finished move:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L49

Within `_action_assign` because finished moves originate from the production location, they bypass the normal reservation logic at: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2086

So `_action_assign() `then tries to reuse an existing move line. However, it only searches for move lines whose `location_dest_id` matches the move's destination location
(WH/Stock):
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2108-L2117

The existing move line has `WH/Stock/Fridge` as its destination, so it does not match. As a result, a new move line is created for the finished move: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2182

The new move line gets the lot value from the Manufacturing Order: https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/models/stock_move.py#L557

Later, when Produce All is triggered,` button_mark_done()` calls` _post_inventory()`:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L2236

Because the finished move already has a `lot_id`, the condition below is not satisfied:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L1929-L1933

Therefore, the `lot_id` is not assigned to the move line that was created earlier.

When `button_mark_done()` validates the finished move lines, it finds that one move line has no lot assigned and raises an 'Invalid Operation' error.

## Solution:
Allow the user to produce the Manufacturing Order after changing the quantity. Increasing the quantity is a valid operation, so the user should not be blocked from completing the production afterward.

opw-6563498

Forward-Port-Of: odoo/odoo#289725
Forward-Port-Of: odoo/odoo#289171

stock_*:
*stock_account, stock_dropshipping, stock_landed_costs,
sale_stock_margin

**Problem:**
dropship moves impact the average cost 
of products which can lead to negative balance 
in stock valuation account

**Steps to reproduce:**
On a new db with no demo data and stock_dropshipping, 
sale_management and accountant module installed 
(bug also reproducible in runbot with same steps, 
but it's easier to see the negative impact 
on accounting on a new db) : 
1) enable dropshipping
2) create a storable product with average perpetual
category
3) in the purchase tab set a vendor with a price of 10
4) in the inventory tab select the dropship route
5) create PO for 1 unit @ 5, validate receipt and confirm bill
6) confirm a SO for 1 unit of the product
7) confirm linked PO and validate dropship move
8) confirm invoice and vendor bill 
-> see how the standard price is now 7.5

9) remove dropship route from the inventory tab of 
the product
10) confirm a SO for 1 unit of the product
11) validate delivery and confirm invoice
12) open 'inventory valuation' view

**Current behavior:**
the initial balance of stock valuation is -2.5

**Expected behavior:**
it should be 0 (there shouldn't be a negative 
initial balance if all invoices and bills are confirmed)

**Cause of the issue:**
The issue happens after step 8)
The problem is that the dropship has an impact on the 
average price of the product but not on the accounting.

Before the dropship we have 1 unit in stock @ 5
and the stock valuation account has a balance of 5 
(from the bill), so all is good.

The dropship then changes the standard price to 7.5.
That's because currently, in _run_average_batch()
the dropship move first impacts average cost like 
an incoming move with a value of 10 (at this point we 
have 1 move @ 10 and 1 @ 5 so average cost is 7.5)
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L493-L500
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L505-L510

and then it impacts the value as a regular outgoing move
(meaning it leaves the inventory at the average cost of 
7.5) and does not impact the average cost (which is the 
basic behaviour of outgoing moves)
https://github.com/odoo/odoo/blob/bcaa8b6b00fa1f16513d680c5187fd424bc7cf8c/addons/stock_account/models/product.py#L515-L517
https://github.com/odoo/odoo/blob/60b5b99d569dbe183ef9c980217ccfe9bf243756/addons/stock_account/models/product.py#L522

Therefore after step 8), the standard price is 7.5 and 
we have a unit in stock so, in the inventory valuation 
view the ending stock is 7.5$. 
But the dropship did not impact the stock valuation 
account so the initial balance is still 5$ and we have 
lines with credits and debits of 2.5$ in the the stock 
variation section.

After steps 9 to 12, both the initial balance and ending stock
decrease by 7.5 (which is expected), leading to a negative
initial balance in stock valuation.

**fix:**
We don't take into account the stock move 
from dropships in the avco computation

In master we also revert this commit 
https://github.com/odoo/odoo/commit/64163799f491f1f97c0448a4a703d27e2caf31de
the stay consistent

**tests:**
The fix requires modifications in a few tests:
- test_dropship_bill_standard_price_update 
checks that  the bill of a dropship move impacts
the standard price, so we delete this test
- test_lot_normal_3, the asserts on the total_value 
still make sense but not those on standard_price
- test_dropship_kit_bom_updates_component_standard_price
test_average_cost_dropship_in_negative_quantity,
test_out_move_validate_as_stock_user:
standard price should not be impacted by dropship

Task 6515358

Forward-Port-Of: odoo/odoo#287320
Forward-Port-Of: odoo/odoo#285576

# How to reproduce
- Create the following categories :
	- Category A
		- Category B, Child of Category A
	- Category X
		- Category Y, Child of Category X
		- Category Z, Child of Category X
- Create a published product for category B & Z
- Go to the Shop page
- Enable the Sidebar Categories
- Log out
- Go to the Shop page

# The issue
The link for the Category Z is broken and clicking the Category does nothing.

# Cause
When rendering the recursive template for the categories : https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website_sale/templates/shop_page_templates.xml#L1291 https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website_sale/templates/shop_page_templates.xml#L1310

The rendering engine will fetch the values for the `website_url` field for every `child_id` of every Category because of the prefetch mechanism, even the one public users dont have access to : https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/addons/website_sale/security/ir.access.csv#L16

During the compute of that field, the records will be ordered in this way :

1) Category B => User has read access
2) Category Y => User does NOT have read access, because no product 
3) Category Z => User has read access

So an access error will be raised here for the 2nd Category : https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/addons/website_sale/models/product_public_category.py#L149

Which will be intercepted by the fallback of the getter, that retries the compute with only the first record. This will succeed because the user has access to that record :
https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/odoo/orm/fields.py#L1827-L1828

The issue is that the call to `super()` at the start of the compute already assigned a value to all the records, so all Categories have a value in the cache for `website_url`, even after the fail of the compute :
https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website/models/mixins.py#L255-L258

So when trying to access Category's Z `website_url`, we'll get '#', without any recomputation being done because of the cache value

opw-6481175

Forward-Port-Of: odoo/odoo#284673

### Steps to reproduce

Set a credit limit of 1.000 on a customer, then:

1. Create a Sale Order for a product with Invoice Policy on **Delivered Quantities**, over that amount → the warning shows. Good.
2. Confirm it, and deliver nothing.
3. Create a second order for the same customer → the warning never shows, even though the customer is already over the limit.

### Solution

The ordered quantity is what the customer committed to, delivered or not. Using `qty_to_invoice` instead of `uom_qty_to_consider` or `qty_delivered`

Introducing invoice_status in sales domain for `_compute_credit_to_invoice`: `untaxed_amount_to_invoice` still follows the invoicing policy, while `amount_to_invoice` no longer does. On a confirmed order for a delivery-based product with nothing delivered:

```
    line.untaxed_amount_to_invoice = 0       # still gated by qty_delivered
    line.invoice_status            = 'no'
    order.amount_to_invoice        = 2000    # fixed by this PR
```

The domain filters on the first one, so the order is dropped from the search before its amount is ever read and `credit_to_invoice` stays at 0.`'no'` is the stored marker for a confirmed line that is not invoiceable yet, which is exactly what the first clause misses.

ticket: [6480211](https://www.odoo.com/odoo/project/967/tasks/6480211)

Forward-Port-Of: odoo/odoo#289305
Forward-Port-Of: odoo/odoo#285578

Example of steps:

- open any form view with a date field
- navigate to this date field with tab
- For example clicking on the previous field and pressing tab
- type another date press enter (without opening the picker)
- save
=> The change has not been saved.

`onInputKeydown` closes the picker on Escape and on Enter the same
way: by calling `saveAndClose()` directly, without first calling
`updateValueFromInputs()` to parse the raw text typed in the input
into the reactive `pickerProps.value`.

This doesn't work when the calendar popover was never opened
(i.e. the value was typed by hand instead of picked visually),
`saveAndClose()` calls `apply()` directly, which only pushes
`pickerProps.value` to `onApply`. Since that value was never refreshed
from the input's text, `apply()` sees no change and silently returns
without calling `onApply`, so the typed value is lost.

Every other confirmation path (`onInputChange`, the popover's `onClose`, and `Ctrl+Enter`) already calls `updateValueFromInputs()` before proceeding, so plain Enter was the only path missing it.

To fix this we call `updateValueFromInputs()` before `saveAndClose()` in the Enter/Escape case, like every other confirmation path already does.

opw-6511435

Forward-Port-Of: odoo/odoo#286289
Forward-Port-Of: odoo/odoo#285963

Description of the issue/feature this PR addresses:
The Factur-X Refactoring (https://github.com/odoo/odoo/pull/284123) introduced an error that can result in the generated XMLs not being compliant due to the partner name being missing (BT-44)

Current behavior before PR:
When a contact has an invoicing address without a name set, then the new Factur-X generation does not fall back to the parent name, leaving the corresponding XML entry empty, which is therefore pruned, leaving the Factur-X without a BT-44 and thus failing BR-07

Desired behavior after PR is merged:
The new generation method uses the same data source and fallback method as the old Factur-X generator, pulling the `display_name` of the `commercial_partner_id` if the address doesn't have a `name`. This greatly reduces the chance of a generated Factur-X failing BR-07.



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

Forward-Port-Of: odoo/odoo#289661
Forward-Port-Of: odoo/odoo#289498

# How to reproduce
- Go to Settings > Default Terms & Conditions > Preview
- Open the editor
- Add a Content Block
- Add an Accordion in that Block
- Save

# The issue
The accordion gets messed up and trying to add a new item to that accordion raises a traceback

# Cause
`invoice_terms_html` is an html field with some sanitization enabled : https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/account/models/company.py#L172

This sanitization will remove the accordion snippet's buttons that controls the functionality of the snippet :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website/views/snippets/s_accordion.xml#L9

This issue was already addressed by :
https://github.com/odoo/odoo/commit/b6b4db5fb5690436a4284f6a22abf9f3b346a324

But it is not enough in the case of the accordion. The buttons will be removed by the lxml clean.Cleaner :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/odoo/tools/mail.py#L364

# Proposed Solution
Disable sanitization entirely, like for blog's content, which can also be edited in the website editor :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website_blog/models/website_blog.py#L29

opw-6500378

Forward-Port-Of: odoo/odoo#285255

Currently, if you refund an order fro the backend it is possible to modify the qty as if to refund more than the original order qty.

Steps to reproduce:
-------------------
* Make an order from the shop (1 product, qty 1)
* Validate the order
* Go backend
* Find the order and select the refund button
* Change qty from -1 to -3
* Save and continue the refund process
> No problem refunding more than the original quantity

Why the fix:
------------
In the frontend we cannot refund more than the original quantity, we assume the same should be in the backend process.

The most simple way to do this is by doing a difference between the quantity from the original order and all the refund lines linked.

From `self.refunded_orderline_id.refund_orderline_ids` we need to exclude the line that represents self as it holds the quantity before the onchange and we care about the quantity we're trying to write not the previous (allegedly correct).

opw-6328635

Forward-Port-Of: odoo/odoo#287209
Forward-Port-Of: odoo/odoo#281405

There was a difference between the actual and expected NET.

**Causes**
- rules existed for both SOCSO Act 800 and EIS, but Act 800 seems to be the official name of the Employment Insurance System (source: https://www.perkeso.gov.my/images/dokumen/Rate_of_Contribution_ACT_800.pdf). Keep the ACT 800 one as its matches the expected amount.
- there was a double counting of the SOCSO employee contributions (4 and 800) , as `l10n_my_rule_socso_employee` (the sum of both) was added to the total deductions.

**Change**
Before: 3500/month wage results in a 3108 NET.
<img width="1181" height="533" alt="before" src="https://github.com/user-attachments/assets/cdf4420f-e2cf-4dc7-9488-6bde3f1f9961" />
After: 3500/month wage results in a 3090.85 NET:
	- 6.90 SOCSO Act 800 Employee
	- 6.90 SOCSO Act 800 Employer
	- 17.25 SOCSO Act 4 Employee
	- 60.35 SOCSO Act 4 Employer Which seems consistent with online sources (https://payroll.my/)
<img width="1181" height="425" alt="after" src="https://github.com/user-attachments/assets/7fb41186-dbb4-4d7a-ac9a-14fb56efc4bc" />

Other fix: while not affecting the calculation, 'SOCSO Employer Share' appeared as incorrect, the two rules SOCSO_800_EMPLR and SOCSO_4_EMPLR should have the same sign.

opw-5976362

Forward-Port-Of: odoo/enterprise#131153
Forward-Port-Of: odoo/enterprise#118138

## Steps to Reproduce:
- Install the Subscriptions module with demo data.
- Create a quotation containing a subscription product.
- Set a recurring plan and confirm the quotation.
- Create an upsell quotation or a renewal quotation.
- Cancel the original subscription.
- Remove the recurring plan from the cancelled subscription.
- Open either the upsell or renewal quotation and confirm it.

## Error:
`TypeError - '>=' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
Since Commit https://github.com/odoo/enterprise/commit/315be581a4212b46191e0c4f82b02a2c3fde51dc#diff-07cf1dda5423f99452a763a54fb6e7fdbb861e19b1a9dca00cab093a832490a9, `plan_id` is no longer required when a subscription is in the cancelled state.

During the confirmation of an upsell or renewal quotation, the parent subscription's next invoice date is used for several date validations. However, if the parent subscription is cancelled and its plan is removed, the `next_invoice_date` is computed as False. Comparing a date object with a boolean value leads to an error.

## Fix:
This commit adds an extra check before using the next invoice date.

sentry-7661150764

Forward-Port-Of: odoo/enterprise#132329
Forward-Port-Of: odoo/enterprise#128093

Currently, an error occurs when a user clicks on a cell in the aged partner balance report.

**Steps to Reproduce:**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Reporting` > `Partner Reports` > `Aged Receivable`.
 - Click on the `date filter`, select `Open On`, and set `any date`.
 - Click on any `amount` in the `Total Aged Receivable line`.

`TypeError: the JSON object must be str, bytes or bytearray, not dict`

After the [recent commit] that adds the context to the action, when preparing the action to open 
the journal items corresponding to the selected cell in the aged partner balance report, the 
context is added to the action [1]. When an "Open On" date is set, the code attempts to 
convert the context using json.loads() before adding the search_default_open_on key to 
it [2]. but, the context is already a dictionary, which raises the error [3].

This commit ensures that, since the action context is already a dictionary, the search_default_open_on 
key and its value are added directly to the context.

[recent commit]: https://github.com/odoo/enterprise/commit/9678a1b987a5aa87922b72d972dd7f73a689afee

[1]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L357-L359

[2]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L362

[3]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L361

sentry-7685491449

Forward-Port-Of: odoo/enterprise#129142

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Forward-Port-Of: odoo/enterprise#132332
Forward-Port-Of: odoo/enterprise#88495

On a multi-level BOM where an intermediate component has a 0-day produce delay, the actual indirect demand shown on its own components in the Master Production Schedule could land one full period (e.g. month) too early, even though the indirect demand *forecast* for the same component was already correct.

Steps to reproduce:
-------------------
* Build a 3+ level manufactured BOM,
  - Finished (produce_delay 1 day) 
  - Semi-Finished 1 (produce_delay 0) 
  - Semi-Finished 2 (produce_delay 0)
* Add all three products to the MPS (activate indirect demand and actual indirect demand).
* Forecast 1 demand for Finished in month T.
* Replenish Finished for month T
  - Semi-Finished 1 indirect demand correctly lands in T-1 (the 1-day produce delay move it to the next month)
* Replenish Semi-Finished 1 for T-1
 --> Semi-Finished 2's actual indirect demand lands in T-2 instead of T-1.

Observation:
-------------
When running action_replenish it will create a procurement, this procurement date will be calculated in MrpProductionSchedule._get_procurement_extra_values, this function always use the period's date_start as the procurement's date_planned: https://github.com/odoo/enterprise/blob/e2aa3073dafa9377654c761e371a660415db1e88/mrp_mps/models/mrp_mps.py#L773 This combined with a 1 hour delta when creating a mo, moved the newly created MO to the month prior (_run_manufacture->_prepare_mo_vals->get_date_planned): https://github.com/odoo/odoo/blob/1a8c6053709cb254f6a5297d72f43dd48aad1b96/addons/mrp/models/stock_rule.py#L172 https://github.com/odoo/odoo/blob/c1ec73be8e16b57c8cf7e4d0c3a915dd9fd6c78b/addons/mrp/models/stock_rule.py#L204

When retrieving the information for the mps calculation, it will be the date_range of the previous month:
https://github.com/odoo/enterprise/blob/d3b7c312390d2c0026cc150055f08938c33f4d6f/mrp_mps/models/mrp_mps.py#L473
In that date range is added to indirect_outgoing_qty since it location_dest is a 'production':
https://github.com/odoo/enterprise/blob/d3b7c312390d2c0026cc150055f08938c33f4d6f/mrp_mps/models/mrp_mps.py#L1164
https://github.com/odoo/enterprise/blob/d3b7c312390d2c0026cc150055f08938c33f4d6f/mrp_mps/models/mrp_mps.py#L1171-L1172
With the key still in the previous month

opw-6519076

Forward-Port-Of: odoo/enterprise#130525

Opening a product creation form from the purchase catalog
raises a traceback. 

### Steps to Reproduce
1. Go to Purchase > Orders (or Requests for Quotation).
2. Open any order with a Vendor selected.
3. Click 'Catalog' on the order lines table.
4. Search for any non-existent product to trigger the empty state.
5. Click 'Create a product' from the no content helper.

### Traceback
```pytb
Traceback (most recent call last):
  File "odoo/addons/web/models/models.py", line 2232, in onchange
    defaults = self.default_get(missing_names)
  File "odoo/orm/models.py", line 1401, in default_get
    defaults[fname] = field.convert_to_write(value, self)
  File "odoo/orm/fields_relational.py", line 759, in convert_to_write
    if record != origin:
  File "odoo/orm/models.py", line 6117, in __eq__
    return self._name == other._name and set(self._ids) == set(other._ids)
TypeError: cannot use 'dict' as a set element (unhashable type: 'dict')
```

### Issue
The purchase catalog action helper (PR odoo/odoo#164131) sets the current
vendor as default on the new product using a bare dictionary:
```python
context = {'default_seller_ids': [{'partner_id': vendor_id}]}
```

Following commit 188c81575130 (PR odoo/odoo#272499), a check was added to 
`convert_to_cache()` to optimize lists of record ids (`[1, 2, 3]`):
```python
elif isinstance(value, list) and value and not isinstance(value[0], (tuple, list)):
```
The `convert_to_cache` expects x2many default values to be passed as 
formal commands or ids.Because the caller passed a bare dictionary instead 
of a command, the dictionary was mistakenly placed into `record._ids`, causing a
TypeError when comparing records (`set(self._ids)`).


### Fix
Use `x2ManyCommands.create` from `@web/core/orm_plugin` to properly format
`default_seller_ids` as an x2many create command.



Related: odoo/odoo#272499  
Related: odoo/odoo#164131

Forward-Port-Of: odoo/odoo#288282

We introduced the ability to adjust child line quantities from the parent section's quantity fields in 34c47e5493bc36af338efbb54050e060b04f8ea3. However, this caused an issue when discarding a change made to a section's quantity.

Previously, the child line quantity adjustment was triggered from the field's `useEffect`. Since `useEffect` runs on every re-render, discarding a section quantity change could trigger the adjustment again. This could result in two nchanges for a single line operation and potentially leave child line quantities in an inconsistent state.

We already have `batch_onchange_sol` to handle onchange operations involving both virtual and saved records. It can handle the section quantity change and the corresponding child line quantity adjustments in a single ORM call.

To achieve this, the quantity adjustment logic is moved from the field component to the `Record` class, specifically into `_getOnchangeValues`.

The flow is now:

1. `record.update()` receives the section quantity change.
2. `_getOnchangeValues()` detects that the updated field is the section quantity.
3. It adjusts the quantities of the corresponding child lines as part of the same onchange values.
4. `batch_onchange_sol` sends the complete set of changes to the ORM in a single onchange call.
5. The resulting values are applied without relying on field re-renders.

This ensures that the section quantity and its child line quantities are always updated together, while avoiding duplicate onchanges and side effects caused by `useEffect` re-renders.

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

Forward-Port-Of: odoo/odoo#287843

When moving a document into a folder (e.g., via drag and drop), the
document fails to inherit the group access rights defined on the
destination folder if that folder does not have an owner. While direct
uploads correctly apply the groups, moved documents only inherit
partner access rights in this scenario, potentially leaving group
members without the expected access.

This occurs because group access rules were inadvertently filtered out
during the rights sync when the system evaluated the missing folder owner.

This commit ensures that group-based access rules are correctly
retained and applied to the document when it is moved into a folder,
regardless of whether the destination folder has an owner.

Steps to reproduce:
- Create a new folder and ensure the "Owner" field is empty.
- Add a group to the folder's access rights.
- Drag and drop a file from elsewhere into that folder.
- Notice the document doesn't inherit the group from the parent folder.

Task-6585315

Forward-Port-Of: odoo/enterprise#132235