Issue:
Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id

Step to reproduce:
- Activate analytic accounting
- Go to Accounting Report -> General Ledger -> Options
- Activate "Analytic Group By"
- Create an invoice
- add a line with an analytic account
- Confirm the Invoice
- Duplicate the invoice
- Confirm the second invoice
- Go to the General Ledger
- Group By the analytic account you used

Current Behavior:
General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger.
Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry.

Expected behavior:
- "View Journal Entry" should send to the right entry

Proposed Solution:
To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id.

However, lines are merged into only one single line.

opw-5267981

Forward-Port-Of: odoo/enterprise#103169

When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.

Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
  Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
     - Allocation Type: Accrual Allocation
     - Set the Time Off Type and Accrual Plan created above
     - Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``

Traceback:
``IndexError: list index out of range``

https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.

sentry-6874651972

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

Forward-Port-Of: odoo/odoo#243315
Forward-Port-Of: odoo/odoo#227201

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

In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type.

While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types:

Example error:
```
File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content
raise KeyError(content_type)
KeyError: '*/*'
```

This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive.

While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant.

OPW-5425093

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

Forward-Port-Of: odoo/odoo#242193

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

…me tokens greedily.

Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033

This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this:

There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this:

(base >= 100) and (base * 0.05) or (base * 0.07)

<img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" />

This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100.

This formula will work sometimes, but sometimes, it will fail with this error.

<img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" />

The position of the error is the '=', because the '=' is not a valid token in this list:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10.

The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error  appears sometimes?

So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127

sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle.

When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail.

But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail.

You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error.

The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#242661

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/8d1d32160 [REL] 18.3.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3d2d2e6da [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782)
https://github.com/odoo/o-spreadsheet/commit/de60a1cd2 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/61bbf4ce1 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885)
https://github.com/odoo/o-spreadsheet/commit/42d525737 [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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