Steps to reproduce

Scenario A

1. Go to Website → drop an Image Gallery snippet → A default height value
appears in the `"Height"` input.

2. Select an image → change its order in the carousel → The snippet height
is automatically reset to `70%` of the screen height.

Scenario B

1. Change the height value of the snippet from the `"Height"` option.

2. Select an image → change its order in the carousel → The snippet
height is again reset (and the option value is overridden).

Issue

The original height behavior was introduced in [1] to make the slideshow
mode auto-adapt to `70%` of the viewport height.

This diff also removed height CSS for other modes where the height
should depend on the content [2]

Subsequent adaptations:

[3] added a default height (`500px`) in XML,

[4] removed it during a design refactoring,

[5] restored the possibility to control the height of the image gallery
snippet using the `"Height"` option.

Keeping the same JS logic that forces the snippet height, led to the
behavior explained above: even when the user manually sets a height, any
action triggering `slideshow()` (e.g., image reorder) forces the height
back to 70% of `window.innerHeight`.

Fix

1. Remove the outdated JS code that automatically updates the height.

2. Keep the slideshow behavior consistent with [2] by excluding it from
the height CSS removal logic.

The snippet now starts with a default height and only changes when
edited through the `"Height"` input.

Additional fixes

This commit also fixes a few minor issues in the new carousel items
template introduced in [4]: items having an `"undefined"` class, and a
missing margin style in the main snippet template.

[1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf
[3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
[4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609
[5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c

task-3414281

Forward-Port-Of: odoo/odoo#242385
Forward-Port-Of: odoo/odoo#126766

This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323

When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B

### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain

This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time

### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected

### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken

### Tickets:
18.0: opw-4409744
17.0: opw-5237430

Forward-Port-Of: odoo/odoo#243059
Forward-Port-Of: odoo/odoo#239667

Issue
-----
When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency.

Example:
	Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate.
	Sell for 15 EUR of products => the delivery picking shows 10 EUR

Steps to reproduce
-----
- Activate EUR currency at 1.5 EUR = 1 USD rate
- Setup company in USD
- Setup INTL FEDEX delivery method
- Create a dummy product with a 10 USD sale price
- Create a pricelist using the EUR currency
- Create a sale for some INTL client
	- set pricelist to EUR
	- add dummy product
	- add INTL FEDEX shipping
	- confirm the sale
- Confirm the linked delivery

> Message in chatter shows a price of 10 EUR instead of 15 EUR

Cause
-----
The problem is with the `carrier_price` field of `stock.picking`.

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21

The value is set by

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155

which gets its' value from the response of

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157

We then go through

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382

where we call

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484

The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598

we should also filter to ensure the rate matches the order's specified currency.

-----
Ticket:
opw-5419724

Forward-Port-Of: odoo/enterprise#103737
Forward-Port-Of: odoo/enterprise#103232

Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None.

Steps to reproduce:
1) Install 'account_reports' module with demo data and enable developer mode. 
2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable.
3) Click on 'gear icon' to navigate advance options. 
4) Click on the Options tab and set Integer Rounding to 'Nearest', click save
   and close adv options.
5) Expand a partner line.

Error:
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'`

Root Cause:
When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType.

FIX:
Skip the rounding if the value received at [1] is None.

[1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329

opw-5392883

Forward-Port-Of: odoo/enterprise#102417

**PROBLEM**
When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one.

**STEP TO REPRODUCE**
According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like:
1. Request a range.
2. Exhaust all number from this range by sending invoices to DIAN.
3. Request a new range.
4. sync with DIAN. (notice the range selected is still the old one).
5. Try sending a new invoice to DIAN and notice there is an error.

**CAUSE**
In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't  check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.).

Forward-Port-Of: odoo/enterprise#103943

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#238989

**Steps to Reproduce:**

1. Create an invoice with a due date 20 days prior and an amount of $100
2. Create a payment of 120$
3. Create an invoice of 100$
4. Reconcile the second invoice with the payment
5. Go to the customer record.
6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed".

[Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing)

**Cause:**
- The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404)
- In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due.

**Solution:**
Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679)

[opw-5216007](https://www.odoo.com/odoo/project.task/5216007)

Forward-Port-Of: odoo/enterprise#101874