Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point.

## Steps to replicate:
- Install Quality, Purchase, IoT
- Quality > Quality Control > Control points
- Create a new Control point with
   - Type: Take A Picture
   - Operations: My Company: Receipts
- Create and confirm a purchase order for a test product
- Receipts > Quality Checks > Take A picture

## Observed behavior:
TypeError: Cannot read properties of undefined (reading '0')

## Root cause:
This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined.

These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined.
[1]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 
[2]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 
[3]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 
[4]:
https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32

## Solution:
Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4]

opw-6010095

Forward-Port-Of: odoo/enterprise#110615

**Behavior:**
Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number.

The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner.

**Steps to reproduce:**
- Log to a Belgian company
- Create a contact that is a person
- Add the 281.50 tag to them
- Create a credit note for any positive amount for that person and set the date to the previous year
- Make sure the account used in the credit note has any 281.50 x tag assigned
- Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note
- When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact

opw-5930339

Forward-Port-Of: odoo/enterprise#111310

Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx).

- Fill the text field with a value (e.g., "John Doe") and save the PDF.
- (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field).
- Upload this PDF to the Sign app.

**Current behavior:**
The text field's string value is ignored and replaced with a checkmark (✓).

**Expected behavior:**
The text field should correctly render the string value that the user entered.

**Cause of the issue:**
In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713).
However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons.

**Solution:**
This PR fixes the issue safely for stable versions across two commits:

[REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit.

[FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. 

Task: 6018260

Forward-Port-Of: odoo/enterprise#110292

The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.

This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.

In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.

For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.

Task: 6043957

Forward-Port-Of: odoo/enterprise#111140

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#110324
Forward-Port-Of: odoo/enterprise#105115

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#110874
Forward-Port-Of: odoo/enterprise#99784

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353

Forward-Port-Of: odoo/enterprise#110696
Forward-Port-Of: odoo/enterprise#108912

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

Forward-Port-Of: odoo/odoo#248142

BUG 1:
-----------

**Steps to reproduce:**
1. Install Time Off and Timesheets with demo data.
2. Create a time off for an employee and approve it.
3. Check the related timesheet entry for that employee.
4. Delete the approved time off.
5. Check the timesheet entries again.

**Issue:**
The timesheet entry remains even after the related time off record is deleted.

**Cause:**
Following commit 944c11e, admins can delete [approved time off ](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L956-L959)records. 
The relationship between the leave and the analytic line (timesheet) did not
have a deletion policy defined. When the leave was [unlinked](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L961-L964), the analytic
line remained without its parent reference.

**Solution:**
Explicitly remove related timesheet entries before deleting the leave record.


BUG 2:
-----------


Currently, refusing/cancelling a time off record can lead to orphan 
timesheets/duplicated hours (16h instead of 8h) if a public holiday 
exists on the same day.

**Root cause:**
The issue comes from this write method:
https://github.com/odoo/odoo/blob/79ff1d63caed2c1058aa338947b9af90ebb6cd20/addons/project_timesheet_holidays/models/hr_leave.py#L128-L130
The method first unlinks the holiday_id from the timesheets
and then attempts to delete them.

However, once the holiday_id is set to False, the timesheets are
no longer linked to the leave. As a result, leave.timesheet_ids becomes empty,
and nothing is deleted. This leads to orphan timesheet records.

When the leave is later refused or cancelled, a new public holiday timesheet
entry is generated (if applicable), resulting in duplicated timesheet entries
for the same day.

**Steps to reproduce:**
1. Create a time off for one day and validate it (8h timesheet generated).
2. Create a public holiday for the same day.
3. Observe that leave duration becomes 0, but the timesheet remains.
4. Refuse or cancel the time off.
5. Observe two timesheet entries for the same day (16h total).

opw-5384428





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

Forward-Port-Of: odoo/odoo#247155

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

   * Enable **Cash Rounding**
   * Set a **Rounding Method**
   * Enable **Only on cash methods**
3. Create a product:

   * Sale Price: 260
   * Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
   *(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

Forward-Port-Of: odoo/odoo#254844

Currently when the user creates an invoice the delivery date is set incorrectly.

<h2>Steps to produce:</h2>

* Set system timezone to Asia/Kolkata and time to 5:00
* Install Sales, Inventory
* Create and confirm a sale order
* Go to Delivery and Validate the delivery
* Go back to the Sale order and create an invoice.


<h2>Observed Behavior:</h2>
The delivery date on the customer invoice is set to one day before the current date, even though the effective date for the delivery correctly reflects the system date and time.

<h2>Root cause:</h2>

This issue occurs because, when a delivery is validated, the `date_done` field is set using the current time in UTC at [1], because odoo operates in UTC by default. This value is then used to compute the effective date on the
sales order at [2], which in turn is used to determine the delivery date on the invoice at [3] and [4].

Users see the effective date on the delivery in their own timezone because `Datetime` fields are converted from UTC to the user’s timezone on the client side as stated in [5]. However problem arises from a type mismatch. The delivery date field is of type `Date`, while the effective date is a `Datetime`. As a result, when the value is assigned at [3] or at [4], only the date portion is passed.

Because a Date field does not carry any timezone information, no timezone conversion occurs, leading to the observed discrepancy.

[1]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/stock/models/stock_picking.py#L1274
[2]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L87-L88
[3]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/account_move.py#L122
[4]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L301
[5]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/odoo/orm/fields_temporal.py#L214-L217

## **Solution:**
Using the `context_timestamp` function makes it possible to work with the `Datetime` in the client’s timezone, which can then be used to correctly assign the delivery date on the invoice.


opw-5391189

Forward-Port-Of: odoo/odoo#247122

Purpose
=======
Fix the "This question requires an answer" alert which is displayed under the question even if it's the first time the user sees it.

Specification
=============
Following odoo/odoo#215237 conditional questions can now be displayed in the post-submit flow. The purpose was to give the user the chance to see and answer the conditional questions that are triggered by a mandatory question that was skipped.

However the condition to display this error alert was only relying on the fact that the question was considered post-submit or not. But now that the post-submit questions also includes the conditional questions that are waiting for answer, this condition is not enough anymore.

Making the condition more precise to be sure that the error is displayed only if the questions is considered post-submit AND it's already the post-submit flow or it's the pre-submit flow and the question was effectively skipped by the user.

Task-6048598


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

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft.

The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI.

In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow.

While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix.

The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo.

opw-5912848

Forward-Port-Of: odoo/odoo#250886

An error is raised when we try to acces the inventory valuation if a move has been returned and the quantity set on the original move is changed to 0

Steps to reproduce:
1. Install Accounting and Inventory
2. Create a product called "Product" and set the Category to "Goods"
3. Go to Inventory > Configuration > Categories, open category "Goods" and change the costing method to "Average Cost (AVCO)"
4. Go to Inventory > Operations > Deliveries and create a new delivery for any customer with one of product "Product"
5. Validate the delivery, click on "Return" then on "Return All"
6. Validate the return
7. Go back to the original delivery and in Actions, click on "Lock/Unlock"
8. Set the quantity to 0 and save
9. Go to Accounting > Review > Inventory valuation
10. Change the day to any day after today
11. An error is raised

Issue:
Trying to get the inventory valuation at another day then today will replay the history
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/product.py#L444-L450
Which will call `_get_value()` on the moves related to the product
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/stock_move.py#L388-L391
A ZeroDivisionError will then be raised when trying to get the value of a return move and the original move's quantity is 0
https://github.com/odoo/odoo/blob/873d4d262ed3e85362aa677b5a782d6e7fa00f09/addons/stock_account/models/stock_move.py#L457

Solution:
If the original move's quantity is 0, set the value to 0
This ensures the move is valued at 0 if the move has no quantity. In other words, a move that has no quantity shouldn't be considered to have any value as there really is nothing to value.

opw-5980600

Forward-Port-Of: odoo/odoo#253392

# How to reproduce
- Have atleast one product published on the website. The more products published, the more noticable the issue is
- Edit the website
- Add a table block to a page (Search for table in the "Insert block" popup and pick the first one)
- Add a catalog block to the table. This catalog block needs to be the one with the title "Our latest content".
- Add any other block in the table block to update the table of content

# The problem
The table of contents display the names of the different products. If there are a lot of products, it fills the whole table of content

# Why
The TableOfContentPlugin scans for ```<h2>``` tags to use them in the table of content.
```js
updateTableOfContentNavbar(tableOfContentMain) {
        const tableOfContent = tableOfContentMain.closest(".s_table_of_content");
        const tableOfContentNavbar = tableOfContent.querySelector(".s_table_of_content_navbar");
        const currentNavbarItems = [...tableOfContentNavbar.children].map((el) => ({
            title: el.textContent,
            href: el.getAttribute("href"),
        }));

        if (tableOfContentMain.children.length === 0) {
            // Remove the table of content if empty content.
            this.dependencies.remove.removeElement(tableOfContent);
            return;
        }

        const targetedElements = "h1, h2";
        const currentHeadingItems = [...tableOfContentMain.querySelectorAll(targetedElements)]
            .filter((el) => !el.closest(".o_snippet_desktop_invisible"))
            .map((el) => ({ title: el.textContent, id: `#${el.id}`, el }));
```

The product snippet template uses ```<h2>``` for their product title dispite having the h6 CSS class.

Note that the reason you need to add another block to the table to see the issue is that the table of content is updated before the products are loaded in the catalog.

opw-5992937

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

Forward-Port-Of: odoo/odoo#253002

To compute the inventory valuation report, stock_account builds a valuation context through `_with_valuation_context()` and passes the valued internal/transit locations to stock quantity computation.

Without `strict=True`, stock quantity domains treat these locations as hierarchical anchors and expand them again through the location tree. This is redundant in this specific call site because `_with_valuation_context()` already provides the valued locations to filter on.

On databases with a large location tree, this extra expansion makes the inventory valuation load much slower than necessary.

Using `strict=True` makes quantity computation use the provided valued locations directly.

### Benchmark:
- active products: 5912
- stock moves: ~785k
- internal locations: 4213

| Before  | After  |
|---------|--------|
| 99.285s | 1.853s |

opw-5944584

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

Forward-Port-Of: odoo/odoo#253656

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

Forward-Port-Of: odoo/odoo#253607

### Steps to reproduce:

- Create a product that is not track inventory (`is_storable = False`)
- Set its cost to 50$ and put it in an avco perpetual valuation category
- Create and receive a purchase order for 10 units
- Set the product as track inventory (`is_storable = True`)
- Inventory > Reporting > Stock
- Click on the `unit cost` of your product line
#### > This opens the `stock.avco.report` according to which the total value of your stock is 500$ and the total quantity is 10 units even though do not have any unit in stock.

### Expected behavior:

The line of the receipt should have been counter balanced by an inventory adjustment line to resets the valuation at the same time as the product has been set to `is_storable`

### Cause of the issue:

There is currently no mechanism to counter balance the stock that should have been present in internal locations if the moves done had been processed with a storable product.

opw-5472902

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

Forward-Port-Of: odoo/odoo#254380

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006

Issue:
If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened.

Explanation:
When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves.

Solution:
Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch.

For memory:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 280 MB | 274 MB |
| 500 products with 535,250 moves | 983 MB | 301 MB |
| 500 products with 912,405 moves | 1.7 GB | 337 MB |
| 1000 products with 1,447,655 moves | Mem error | 393 MB |

For speed (in m:ss):
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 0:15 | 0:16 |
| 500 products with 535,250 moves | 1:12 | 1:17 |
| 500 products with 912,405 moves | 2:02 | 2:10 |
| 1000 products with 1,447,655 moves | N/A | 3:53 |

opw-5416006

Co-authored by Cooper Spinelli (spco)

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

Forward-Port-Of: odoo/odoo#250526

*: website_blog, website_event, website_sale

The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-5427353

Forward-Port-Of: odoo/odoo#253985
Forward-Port-Of: odoo/odoo#246328