Opening a picking with a large amount of moves is very slow due to some compute fields

doing this rn to see if tests fail or not

**Pre fix**
/web/dataset/call_kw/stock.picking/web_read# - 786 11.559 51.289:  62.7 Seconds

**Fix 1** - local measurement
/web/dataset/call_kw/stock.picking/web_read - 741 11.252 39.448 - 50.6 Seconds

```
+
+        ins_seed = OrderedSet(ins.ids)
         for out in outs:
             # stop the rollup at the in moves: what feeds them is still outside the warehouse
-            linked_move_ids = out._rollup_move_origs(seen=OrderedSet(ins._ids)) - ins_ids
+            linked_move_ids = out._rollup_move_origs(seen=ins_seed.copy()) - ins_ids
             linked_moves_per_out[out] = self.env['stock.move'].browse(linked_move_ids)
 
```

**Fix 2** (Changes fix 1)
/web/dataset/call_kw/stock.picking/web_read - 784 11.331 27.077 - 33.0 Seconds

```
-    def _rollup_move_dests(self, seen=False) -> OrderedSet[int]:
-        return self._rollup_moves(origin=False, seen=seen)
+    def _rollup_move_dests(self, seen=False, boundary=frozenset()) -> OrderedSet[int]:
+        return self._rollup_moves(origin=False, seen=seen, boundary=boundary)
 
-    def _rollup_move_origs(self, seen=False) -> OrderedSet[int]:
-        return self._rollup_moves(seen=seen)
+    def _rollup_move_origs(self, seen=False, boundary=frozenset()) -> OrderedSet[int]:
+        return self._rollup_moves(seen=seen, boundary=boundary)
 
-    def _rollup_moves(self, origin=True, seen=False) -> OrderedSet[int]:
+    def _rollup_moves(self, origin=True, seen=False, boundary=frozenset()) -> OrderedSet[int]:
         """
             Find all moves in chain depending the direction (origin)
 
             origin: if set (default), returns the origin moves, else return the destinations
+            boundary: ids at which to stop the rollup (excluded from the result). Unlike `seen`,
+                this is never copied or mutated, so callers can share one boundary set across many
+                independent calls (e.g. one per record of a big recordset) without paying its size
+                on every call.
         """
         target_field = "move_orig_ids" if origin else "move_dest_ids"
         if not seen:
             seen = OrderedSet()
-        unseen = OrderedSet(self.ids) - seen
+        unseen = (OrderedSet(self.ids) - seen) - boundary
         if not unseen:
             return seen
         seen.update(unseen)
-        self.filtered(lambda m: m.id in unseen)[target_field]._rollup_moves(origin, seen)
+        self.filtered(lambda m: m.id in unseen)[target_field]._rollup_moves(origin, seen, boundary)
         return seen
```

```
         for out in outs:
             # stop the rollup at the in moves: what feeds them is still outside the warehouse
-            linked_move_ids = out._rollup_move_origs(seen=OrderedSet(ins._ids)) - ins_ids
+            linked_move_ids = out._rollup_move_origs(boundary=ins_ids)
             linked_moves_per_out[out] = self.env['stock.move'].browse(linked_move_ids)
```

**Fix 3**
/web/dataset/call_kw/stock.picking/web_read - 818 5.308 18.648 - 23.9 Seconds
```
     def available_carriers(self, partner, source):
-        return self.filtered(lambda c: c._match(partner, source))
+        # _match_must_have_tags/_match_excluded_tags/_match_weight/_match_volume each
+        # independently recompute data from source.move_ids/order_line, and none of it depends
+        # on which carrier is being checked. Precompute it once here instead of once per
+        # candidate carrier inside .filtered() below (source's lines can be numerous).
+        match_data = self._prepare_source_match_data(source)
+        return self.filtered(lambda c: c._match(partner, source, match_data))
+
+    def _prepare_source_match_data(self, source):
+        if source._name == 'sale.order':
+            lines = source.order_line
+            products = lines.product_id
+        elif source._name == 'stock.picking':
+            lines = source.move_ids
+            products = lines.with_prefetch().mapped('product_id')
+        else:
+            raise UserError(_("Invalid source document type"))
+        return {
+            'product_tag_ids': products.all_product_tag_ids,
+            'total_weight': sum(line.product_id.weight * line.product_qty for line in lines),
+            'total_volume': sum(line.product_id.volume * line.product_qty for line in lines),
+        }
 
-    def _match(self, partner, source):
+    def _match(self, partner, source, match_data=None):
         self.ensure_one()
+        if match_data is not None:
+            return (
+                self._match_address(partner)
+                and (not self.must_have_tag_ids or any(tag in match_data['product_tag_ids'] for tag in self.must_have_tag_ids))
+                and not any(tag in match_data['product_tag_ids'] for tag in self.excluded_tag_ids)
+                and (not self.max_weight or match_data['total_weight'] <= self.max_weight)
+                and (not self.max_volume or match_data['total_volume'] <= self.max_volume)
+            )
         return (
             self._match_address(partner)
             and self._match_must_have_tags(source)
```

Steps to reproduce:
- Set the product category to Automated (perpetual) Inventory Valuation.
- Set up an Analytic Distribution Model for a vendor.
- Confirm a sale order linked to a project, with a line using the
  Dropshipping route for that vendor, then validate the dropship delivery.

Cause of the issue:
A dropship move is weird: the same stock move is linked to both a
purchase line and a sale line at once (one move covers both sides).
When we build the stock valuation entry for that move, two different
modules each add their own analytic distribution on top:
- purchase_stock adds the purchase line's distribution (vendor's ADM,
  already combined with the project account by project_purchase)
- sale_stock also adds the sale line's distribution, which already has
  the project account in it too

Both just do a plain dict union, no normalization. On a normal delivery
or a normal receipt only one of these ever kicks in, but on a dropship
move both fire on the same line, so the project account's share gets
counted twice (100% + 100% = 200%).

Solution:
Don't fall back to the sale line's distribution when the move already
has a purchase line attached (that's the dropship case) — the purchase
line's distribution is already the full, correct one for that move.

The test uses two Analytic Distribution Models (one on the vendor, one
on the customer) instead of the project app, since stock_dropshipping
doesn't depend on project.

opw-6383779

Forward-Port-Of: odoo/odoo#282751

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/493acaf76d [REL] 19.0.51 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dbe0b34980 [IMP] demo: debounce xml template build [Task: 6574005](https://www.odoo.com/odoo/2328/tasks/6574005)
https://github.com/odoo/o-spreadsheet/commit/54b5a6f9a5 [FIX] demo: fix scorecard demo definition [Task: 6573109](https://www.odoo.com/odoo/2328/tasks/6573109)
https://github.com/odoo/o-spreadsheet/commit/fbfc45aaaa [FIX] pivot: wrong running total with collapsed/hidden dimensions [Task: 6569607](https://www.odoo.com/odoo/2328/tasks/6569607)

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>

The`SP` (Split Payment) taxes have incorrect configurations:
- **Tax Grid Tags on `SP` Taxes**: The ve38 grid tag was incorrectly assigned to the tax line instead of the base line.
- **`VE38` VAT Report Formula**: In Tax Report > VAT Report, the line `VE38 - Transactions with parties referred to in Article 17-ter` was using a negative formula `-ve38` and should be `ve38`
- **Tax Group Invoice Label**: Updated the default label on invoices for the SP tax group to display 22% SP instead of 22%.

Steps to reproduce:
- Install `account` and `l10n_it`
- Switch to IT company
- Go to taxes and filter for `SP` taxes
- The tax grid is wrong for the negative taxes since `ve38` should be in the base line instead of in the tax line
- Go in the Tax report > VE VAT Report
- The line `VE38 - Transactions with parties referred to in Article 17-ter` has a negative formula `-ve38`, should be positive `ve38`
- The label on invoices of the tax group should be `4% SP`, `5% SP`, `10% SP` not `4%` etc.

References:
https://www.informazionefiscale.it/IMG/pdf/dichiarazione_modello_iva_2026_agenzia_delle_entrate.pdf
<img width="1413" height="141" alt="immagine" src="https://github.com/user-attachments/assets/7fa15859-beaa-4345-bf81-fedc3f0af2fa" />
https://fiscomania.com/quadro-ve-della-dichiarazione-iva/
<img width="705" height="154" alt="immagine" src="https://github.com/user-attachments/assets/4f23b407-0e4d-4104-9695-f9891ccfd2f2" />

Ticket [link](https://www.odoo.com/odoo/project.task/6543520)
opw-6543520

### Steps To Reproduce:

- Add this content in the HTML editor:
`<h2 class=display-3-fs>heading 2</h2>`
- Select the heading text.
- Click Remove Format.
- Check the font-size input in the toolbar.

### Description of the issue/feature this PR addresses:

- The font-size class was removed from the block element, but the font-size input still displayed the value associated with the removed class.
- The toolbar did not show the correct font size for default block classes (like `o_default_font_size`).
- Applying a new font size inside default block classes created nested spans instead of splitting them.
- The "Remove format" button remained enabled even when selection had no custom formatting (only default block classes).

### Desired behavior after PR is merged:

- The font-size input is updated after removing the font-size class and correctly displays the font size of the resulting block element.
- Update the `getFontSizeDisplayValue` utility to find correct CSS variable dynamically to also find the font size of default block classes.
- Add default font size classes (like `o_default_font_size` and headings) to `format_class_predicates` resource in `font_plugin.js`. This allows them to be split and replaced instead of creating nested spans.

task-6321166

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

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

When a batch recompute of `vies_valid` contains both a parent (commercial) partner and a child sharing the same VAT, and the child happens to be iterated before its parent, the child ends up with `vies_valid=False` instead of the parent's real, freshly-checked value.

**Current behavior before PR:**

`_compute_vies_valid` loops over `self` in whatever order the batch happens to have:

```python
for partner in self:
    ...
    if partner.parent_id and partner.parent_id.vies_vat_to_check == partner.vies_vat_to_check:
        partner.vies_valid = partner.parent_id.vies_valid
        continue
    status = partner._check_vies_iap()
    partner._update_vies_status(status)
```

`Field.compute_value()` removes the whole batch from the "to compute" queue *before* running this loop (it does so upfront, in case the method does not assign every record). So when the loop reaches a child and reads `partner.parent_id.vies_valid` to reuse it, that field is no longer marked "to compute" for the parent, and reading it just returns whatever is currently cached/stored — which, if the parent has not been processed yet in this same loop, is still the old/default value. The child copies that stale value and, being a stored field, keeps it forever: nothing re-triggers its computation afterwards.

Example:
```python
parent = env['res.partner'].create({'name': 'Parent Co'})
child = env['res.partner'].create({'name': 'Child Address', 'parent_id': parent.id})
child.vat = 'BE0477472701'   # queues the child's compute first
parent.vat = 'BE0477472701'  # queues the parent's compute second
child.vies_valid   # False, even though the VAT is valid
parent.vies_valid  # True
```

**Desired behavior after PR is merged:**

Every partner without a parent is always computed before any child that may reuse its value, regardless of the batch's original order — so the child correctly ends up with the parent's real `vies_valid`.

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

Forward-Port-Of: odoo/odoo#287251
Forward-Port-Of: odoo/odoo#279927

The mobile summary element hides the address form on Android

Steps to reproduce:
1. Install eCommerce
2. On android (or using browserstack) and without being logged in, go to the eCommerce
3. Add any product to the cart and go to checkout
4. Click on "Checkout" to enter the address details
5. Open the keyboard by clicking inside the first input
6. The virtual keyboard opens, enter a name and click on "Next" in the virtual keyboard
7. Do this a couple of times: the cart summary element doesn't scroll and the input field is hidden behind it

Similar problem happens when you scroll a bit after clicking in the first input: the cart summary element displayed at the bottom is still visible (on top of the virtual keyboard) which hides part of the page and makes it difficult to navigate the page and fill in the details

Issue:
`sticky-bottom` keeps the element at the bottom of the screen

Solution:
Remove class `sticky-bottom` from `o_mobile_summary` when we click in one of the input

opw-6500503

### 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#285578

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way.

That is not possible today. The field passes the compute as the function object:

    flag_image_url = fields.Char(compute=_compute_field_flag_image_url)

`determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for.

Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike.

This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here.

Steps to reproduce:
- Create a company contact with a delivery address that has no name
- Make a PoS order for the delivery address and pay it
- Open the PoS, open the customer list, and click "Orders" on the company

Issue:
The screen goes blank.

Cause:
The ticket screen is opened with the company name as search term. The server domain searches on `partner_id.complete_name`, so the orders of the address contact are returned too. They are then fuzzy matched on `getPartnerName()`, which returns `false` for a partner without a name, and `fuzzyLookup` calls a string method on it. The error is raised during rendering, so the whole app is destroyed.

Fix:
Make `getPartnerName()` always return a string, and fall back on the parent name, like the complete name does. This way the orders of the address contact are still listed when searching on the company name, instead of being filtered out by an empty name.

opw-6578541

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

**Steps to reproduce:**
- Install Appointment app
- Create an appointment type based on resources, auto-assigned, with two shareable resources linked together
- Set the first resource's capacity to 3 and the second resource's capacity to 4
- From the backend Gantt view, create a booking for 2 people on the first resource
- Create a second booking for 2 people on the same resource, at the same date and time
- First resource is now overbooked with reserved capacity of 4 out of 3
- Try to create an appointment from the website
- Error: "The capacity reserved should be positive."

**Issue:**
When bookings are created from the backend gantt view, the selected resource can be overbooked even if another linked resource still has available capacity.

Then when trying to book an appointment the new booking lines will trigger this constraint:
```py
_check_capacity_reserved = models.Constraint(
    'CHECK(capacity_reserved >= 0)',
    "The capacity reserved should be positive.",
)
```
This is caused by the negative values in:
```py
booking_line_values = []
if appointment_type.schedule_based_on == 'resources':
    capacity_to_assign = asked_capacity
    for resource in resources:
        resource_remaining_capacity = resources_remaining_capacity.get(resource)
        new_capacity_reserved = min(resource_remaining_capacity, capacity_to_assign, resource.capacity)
        capacity_to_assign -= new_capacity_reserved
        booking_line_values.append({
            'appointment_resource_id': resource.id,
            'capacity_reserved': new_capacity_reserved,
            'capacity_used': new_capacity_reserved if resource.shareable and appointment_type.resource_manage_capacity else resource.capacity,
        })
```

**Fix:**
Avoid negative remaining value in resource booking when computing available slots.

Note: Tried to take the capacity already used by overlapping bookings into account when assigning resource booking lines from the backend gantt view. And also force linked_resources booking when trying to book more
than the total capacity to properly dispatch as many slots as possible. But it was breaking `appointment_google_reserve` tests.

opw-6503147

Forward-Port-Of: odoo/enterprise#130520

### Problem

`sign/static/src/scss/iframe.scss` sets the background of `.o_sign_sign_item.o_color_constant` with

```scss
background-color: hsl(0, 0%, 80%) / 0.9;
```

That slash is not the modern CSS alpha syntax. Sass parses it as a division of a color by a
number: `hsl(0, 0%, 80%)` is `#cccccc`, each channel is divided by 0.9 (204 / 0.9 = 226.67 -> 227)
and the rule compiles to an opaque `#e3e3e3`. Constant sign items lose the transparency they were
meant to have and render a shade lighter than the `o_color_responsible_*` items right above, which
do use 90% alpha.

Generating the `sign.assets_pdf_iframe` bundle also logs, every time:

```
DEPRECATION WARNING: The operation `#cccccc div 0.9` is deprecated and will be an error in
future versions. Consider using Sass's color functions instead.
```

### Fix

Use `rgba()`, the way the two `o_color_responsible_*` blocks just above already do.

Compiled with libsass 3.6.5 (the compiler `ScssStylesheetAsset` uses):

| | compiled output |
| --- | --- |
| before | `background-color: #e3e3e3;` plus the deprecation warning |
| after | `background-color: rgba(204, 204, 204, 0.9);`, no warning |

18.0 is not affected: there the rule was written as a plain `opacity: 0.9`. In saas-19.4 the same
declaration already reads `rgba(mix(...), .9)`, so this only brings 19.0 in line with it.

In Ecuador, a company and its branches file under a single RUC, so the
ATS is expected to consolidate all of them. However, currently the
system exports only the active company report.

Steps to reproduce:

- Install the Ecuadorian localization
- Create a parent company and a branch, assign the RUC of the parent to
  the branch, and set the legal name of the branch in Settings
- Post a customer invoice with taxes in the parent (e.g. 750) and
  another one in the branch (e.g. 250)
- Activate both companies in the company selector
- Go to Accounting > Reporting > Tax return
- Select "Report: 104 (EC)", the dashboard shows the consolidated values
- Click on the gear icon next to "Tax Return" and select ATS

Issue:

The exported XML only contains the documents and the totals of the
parent company (750). The branch (250) is omitted.

Analysis:

Currently the ATS export use self.env.company for all searches, which
only retrieve the data of the first company set

opw-6469807

Forward-Port-Of: odoo/enterprise#128430

This is a backport of this [commit](https://github.com/odoo/enterprise/commit/c02b8eccd72758127cc7cdc51ab8ec461a2ec45e)

Issue:
----------------------------------------
Creating a night shift from a template produces a shift spanning over one additional day.

Steps to reproduce:
----------------------------------------
- Create a planning shift template form 23h to 1h the next day (2h)
- It must have a span over 2 working days
- Create a shift and use this template
- The shift spans over one more day

Cause:
----------------------------------------
In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h. Then we count two days and so the end date is offset by one day.

Solution:
----------------------------------------
We should call `plan_days()` without the hour specified so we make sure the first day is included in the count.

opw-6535758

Forward-Port-Of: odoo/enterprise#131140

## Issue

In `ai_livechat`, the "Ask a Human" button shown below the chat composer
when an AI agent is the operator does not check whether a human operator
is actually available on the livechat channel. With a channel configured
for AI-only (no users assigned, rule with
`chatbot_enabled_condition = only_if_no_operator` and an `ai_agent_id`),
clicking the button always returns the notification *"There is no human
agent available at the moment. Please try again later."* — a dead-end UX.

## Steps to reproduce

1. Create an `im_livechat.channel` with no users assigned.
2. Add a rule on that channel with:
   - `chatbot_enabled_condition = only_if_no_operator`
   - `ai_agent_id` set (any non-system AI agent).
3. Open the public livechat URL as a visitor.
4. Observe the *Ask a Human* button below the composer; clicking it
   produces the no-human-available warning.

## Cause

`ChatWindow.showForwardOperatorButton` (in
`ai_livechat/static/src/discuss/core/common/chat_window_patch.js`) only
checks `thread.channel_type === 'livechat' && thread.ai_agent_id`. It does
not consider whether the parent livechat channel currently has any
available human operator.

## Fix

- Expose a new `ai_livechat_has_human_operator` attribute on the
  `discuss.channel` Store payload via `Store.Attr`. The value is computed
  on the fly from the already-existing
  `im_livechat.channel.available_operator_ids` field — **no new stored
  field is introduced** (relevant for stable). The attribute is only
  emitted for livechat channels that have an AI agent set, so the extra
  cost is paid only by AI-backed sessions.
- The web client hides the *Ask a Human* button when this flag is
  `false`. When the attribute is missing (older payloads or non-AI
  threads), behavior is unchanged.

## After the fix

The *Ask a Human* button is hidden when the livechat channel has no
available human operator, matching the "pure AI livechat" setup intent.
Configurations with operators behind the AI continue to show the
fallback button as before.

## Tests

`ai_livechat/tests/test_im_livechat_channel.py::test_store_exposes_human_operator_availability_for_ai_livechat`
covers the Store payload for an AI-backed livechat session without
operators.