- requires: https://github.com/odoo/enterprise/pull/131768

With the webclient redesign deployed for Odoo 17, we used to set `$secondary` to `$gray-300`, a light gray, while Bootstrap's secondary is a dark gray. With the new webclient redesign, it is now sets to `$o-gray-700`, closer to the Bootstrap default, so everything built on `$secondary` got darker: `bg-secondary`, `text-bg-secondary`, `border-secondary`, the `-subtle`/`-emphasis` variants, `alert-secondary` and SCSS rules reading `$secondary`.

Usages that meant "light gray" now use `gray-300`, the former value of `$secondary`, or the closest gray token, so they render as before. To get that light look, don't use secondary, instead, use:
```
  bg-secondary                 -> bg-300
  text-bg-secondary (no badge) -> text-bg-300
  text-secondary (icons, dots) -> text-300
  bg-secondary-subtle          -> bg-100
  text-secondary-emphasis      -> text-700
  border-secondary-subtle      -> border-light-subtle
  alert-secondary              -> alert-light
  border-secondary             -> drop it: `border`, `border-top`, ...
                                  already draw `--border-color`
                                  (gray-300); on a `.card`, use `border`
  $secondary                   -> $gray-300
  $secondary-text-emphasis     -> $gray-700
  @each ... in $theme-colors   -> map-merge($theme-colors,
                                  ("secondary": $gray-300))
```

task-6578378

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

Forward-Port-Of: odoo/odoo#288603

- requires: https://github.com/odoo/odoo/pull/288603

With the webclient redesign deployed for Odoo 17, we used to set `$secondary` to `$gray-300`, a light gray, while Bootstrap's secondary is a dark gray. With the new webclient redesign, it is now sets to `$o-gray-700`, closer to the Bootstrap default, so everything built on `$secondary` got darker: `bg-secondary`, `text-bg-secondary`, `border-secondary`, the `-subtle`/`-emphasis` variants, `alert-secondary` and SCSS rules reading `$secondary`.

Usages that meant "light gray" now use `gray-300`, the former value of `$secondary`, or the closest gray token, so they render as before. To get that light look, don't use secondary, instead, use:
```
  bg-secondary                 -> bg-300
  text-bg-secondary (no badge) -> text-bg-300
  text-secondary (icons, dots) -> text-300
  bg-secondary-subtle          -> bg-100
  text-secondary-emphasis      -> text-700
  border-secondary-subtle      -> border-light-subtle
  alert-secondary              -> alert-light
  border-secondary             -> drop it: `border`, `border-top`, ...
                                  already draw `--border-color`
                                  (gray-300); on a `.card`, use `border`
  $secondary                   -> $gray-300
  $secondary-text-emphasis     -> $gray-700
  @each ... in $theme-colors   -> map-merge($theme-colors,
                                  ("secondary": $gray-300))
```

task-6578378

Forward-Port-Of: odoo/enterprise#131768

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/63c49a88a3 [REL] 20.1.0-alpha.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/62ac6604c6 [FIX] header_resize_editor: remove unnecessary toString() [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4bcd7f6f33 [IMP] zoom: clip out-of-range values instead of ignoring them [Task: 6515617](https://www.odoo.com/odoo/2328/tasks/6515617)
https://github.com/odoo/o-spreadsheet/commit/b7e1d79a4d [FIX] stores: prevent blank grid when zoom value is empty [Task: 6515617](https://www.odoo.com/odoo/2328/tasks/6515617)
https://github.com/odoo/o-spreadsheet/commit/c2bc431a3c [REL] 20.1.0-alpha.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0d33ec1665 [IMP] headers: resize rows and columns from context menu [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/b704a2d032 [REF] viewports: centralize Cartesian coordinate lookup [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/0bd4c2d221 [IMP] headers: cap row and column sizes [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/1307c3f3a9 [REF] env: remove side panel methods [Task: 6566084](https://www.odoo.com/odoo/2328/tasks/6566084)

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>

Users had no easy way to spot sale invoices that are broken from a Veri*Factu standpoint: the account.move field only ever reached the 'rejected' state after a real submission attempt to the AEAT got a negative answer. Invoices that fail local validation before anything is sent (e.g. more than one main tax on a line) generate a l10n_es_edi_verifactu.document with errors filled in but state left empty, so they never showed up as rejected anywhere and could sit unnoticed until someone opened the invoice's Veri*Factu tab.

Widen L10nEsEdiVerifactuDocument._get_state() so a document also counts as 'rejected' whenever it has errors set, regardless of the literal state value. This reuses the existing account.move computed/stored l10n_es_edi_verifactu_state field as the single source of truth instead of duplicating the check against the UI-only, non-stored warning fields, so every consumer of that state (list view badge, search filters) picks up the change for free.

On top of that, add a "Veri*Factu Error(s)" entry to the sale journal's dashboard kanban card, with its own search filter, so these invoices are visible from the accounting dashboard without having to open each one individually.

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

This commit enables ai to add javascript to the page, when it's needed.
By default, scripts are added as a last resort.
Firstly, AI tries to satisfy the user's prompt with HTML/CSS changes,
and when it's not possible, we allow AI to add javascript.

Because static analysis of custom js scripts is quite limited, a
dedicated LLM safety reviewer is introduced to validate proposed code.
To ensure safety, the review fails if any vulnerability or
suspicious pattern is detected, or if the reviewer call itself fails.

In addition, to make sure ai scripts don't mess up the history, and that
we properly clean up everything that ai generated, we prompt AI to wrap
every part of the code that changes the DOM interactively in a wrapper
`__aiProtectMutations`, which handles mutations done right after this
call, so we can easily track the changes made by ai script, in order to
easily reset modifications made by ai before saving the page, or when
entering the edit mode. Also, in the edit mode this wrapper ignores the
mutations made by the script.

To make it more-or-less work acceptably, we stop the execution of ai
generated scripts on entering the translation.
Also, we add a builder option to pause the execution of the ai scripts
in a snippet, so users can easily edit it.
We prompt AI not to hardcode strings on state change, but instead have
a few different blocks with necessary text and show/hide them with
d-none. This way we show every text block when scripts don't run to be
able to edit them.

task-6144157

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c2bc431a3c [REL] 20.1.0-alpha.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0d33ec1665 [IMP] headers: resize rows and columns from context menu [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/b704a2d032 [REF] viewports: centralize Cartesian coordinate lookup [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/0bd4c2d221 [IMP] headers: cap row and column sizes [Task: 6234780](https://www.odoo.com/odoo/2328/tasks/6234780)
https://github.com/odoo/o-spreadsheet/commit/1307c3f3a9 [REF] env: remove side panel methods [Task: 6566084](https://www.odoo.com/odoo/2328/tasks/6566084)

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>

This commit improves the usability of the calendar popover on mobile by adjusting its design to match the bottom sheet.

Prior to this commit, when the popover content exceeded its maximum height, it was not scrollable, causing the content to overlap. This commit also updates the popover to fix this issue.

task-6578705

Requires:
- https://github.com/odoo/enterprise/pull/132185

| Before | After |
|--------|--------|
| <img width="1920" height="925" alt="Screenshot 2026-09-18 at 15 22 27" src="https://github.com/user-attachments/assets/26f83b38-09f1-49b8-b1f5-49ba3a1502f1" /> | <img width="1914" height="925" alt="Screenshot 2026-09-18 at 16 07 26" src="https://github.com/user-attachments/assets/1dc784ab-3224-43da-ba4f-438d482d3c6b" /> |
| <img width="430" height="699" alt="Screenshot 2026-09-18 at 17 52 42" src="https://github.com/user-attachments/assets/4ba909f1-dc0c-477a-bc25-3cb699f9b6cd" /> | <img width="441" height="712" alt="Screenshot 2026-09-18 at 17 51 43" src="https://github.com/user-attachments/assets/6c560e21-242d-45a5-8731-a6a9654c775a" /> |





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

Forward-Port-Of: odoo/odoo#289220

This commit improves the usability of the gantt popover on mobile by adjusting its design to match the bottom sheet.

Prior to this commit, when the popover content exceeded its maximum height, it was not scrollable, causing the content to overlap. This commit also updates the popover to fix this issue.

task-6578705

Requires:
- https://github.com/odoo/odoo/pull/289220

The inner design will be addressed in task-6584243

| Before | After |
|--------|--------|
| <img width="1915" height="928" alt="Screenshot 2026-09-18 at 15 23 12" src="https://github.com/user-attachments/assets/ca304338-92b9-4898-a43e-a2cf7b26b0f2" /> | <img width="1916" height="928" alt="Screenshot 2026-09-18 at 16 08 23" src="https://github.com/user-attachments/assets/f806c753-c059-485f-a2ef-0f53fb7b75bc" /> |
| <img width="434" height="700" alt="Screenshot 2026-09-18 at 17 52 51" src="https://github.com/user-attachments/assets/709a9f4d-cf55-4889-aca2-2747d771391e" /> | <img width="440" height="703" alt="Screenshot 2026-09-18 at 17 52 02" src="https://github.com/user-attachments/assets/c7024d29-2615-4e52-b4ac-7cf542e40223" /> |

Forward-Port-Of: odoo/enterprise#132185

Steps to reproduce:
- Create a DB and Install `Accounting` without demo data
- In Companies > Create New Company with `US` Localization
- Switch to US Company > Add `Avatax` Credentials
- Create a Product with `Avatax Category`
- Create a Invoice > In Other Info `Fiscal Position` - `Automatic Tax Mapping (AvaTax)` > `Compute Taxes`
- In Taxes check newly created tax does not have a account ID

Issue:
AvaTax fiscal position created from chart templates have empty `avatax_invoice_account_id` and `avatax_refund_account_id` fields on a fresh database without demo data.

Problem:
Both fields use [defaults] based on `company.account_sale_tax_id`. During initial CoA loading, `_load_data()` creates the AvaTax fiscal position before `_post_load_data()` sets `company.account_sale_tax_id`. The defaults therefore resolve to an empty recordset and no tax account is assigned. This issue does not occur in databases with demo data because the demo company is already loaded, so `company.account_sale_tax_id` is already set when the AvaTax fiscal position is created.

Solution:
Set the invoice and refund accounts explicitly in the AvaTax fiscal position template to ensure they are correctly assigned during CoA loading.

[defaults]: https://github.com/odoo/enterprise/blob/de17c107651394025e9a3d5cbed8d81bcfc2e76d/account_avatax/models/account_fiscal_position.py#L9-L13

opw-6347128

Forward-Port-Of: odoo/enterprise#132315
Forward-Port-Of: odoo/enterprise#126604

We need an override of Bootstrap's default tooltip border radius because the default value assumes that the users of Bootstrap haven't also overridden the default popover border radius. Since we have, we must also override our tooltip border radius and compute it according to our popover's styling. It follows the usual formula for computing border radii:

Inner radius = Outer radius - Padding

COM Before
<img width="438" height="372" alt="Screenshot 2026-09-18 at 2 40 26 PM" src="https://github.com/user-attachments/assets/5faa8bd3-8048-4f4f-bb69-1082c4f7a40e" />


COM After
<img width="540" height="438" alt="Screenshot 2026-09-18 at 2 39 20 PM" src="https://github.com/user-attachments/assets/58fed7bd-2fac-4a0b-8a8f-10824cce6ff6" />


ENT Before
<img width="444" height="348" alt="Screenshot 2026-09-18 at 2 45 29 PM" src="https://github.com/user-attachments/assets/4d04a647-6667-474a-8a35-6c2845c362b8" />


ENT After
<img width="762" height="492" alt="Screenshot 2026-09-18 at 2 46 38 PM" src="https://github.com/user-attachments/assets/bb4dade6-c497-406a-9f08-110de90d7eeb" />

Forward-Port-Of: odoo/odoo#289320

### Impacted versions

20.0, community. Enterprise sets `$input-focus-box-shadow: 0` (`web_enterprise/static/src/scss/bootstrap_overridden.scss`), so it draws no input ring at all and the misplacement is invisible there.

### Steps to reproduce

1. Open a record with a chatter, e.g. a sales order.
2. Click **Send message**, then the emoji button.
3. The search is autofocused.

### Current behavior

The focus ring is drawn around the input rather than around the search control, so it starts after the magnifier and leaves it outside the ring.

The search is a bordered pill holding a magnifier and a deliberately borderless input:

```html
<span class="o-EmojiPicker-searchContour ... rounded-pill border bg-view">
    <i class="oi ..." data-icon="search"/>
    <input class="form-control border-0 flex-grow-1 rounded-pill ..."/>
</span>
```

`form-control` is on the input, so bootstrap rings the input. Measured at 1600x1000:

| | box-shadow | inset inside the pill |
|---|---|---|
| input | `0 0 0 2px, 0 0 0 4px` | left **22px**, right 1px, top 1px, bottom 1px |
| pill | `none` | |

The 22px on the left is the magnifier. The ring therefore cuts across the middle of the pill, and on the other three sides a 4px ring over a 1px inset spills past the border.

555aa438ca64 ("[IMP] mail, web: improve emoji picker UX") moved the magnifier to the left and made the pill `rounded-pill`, which is what makes this plain to see. It was already misplaced before, with the magnifier then on the right.

### Expected behavior

The ring is drawn around the whole search control, magnifier included.

### Before
<img width="1824" height="282" alt="emoji_before" src="https://github.com/user-attachments/assets/1db54ff9-e39f-46c0-8f65-ce7f5a89856f" />

### After
<img width="1824" height="282" alt="emoji_after" src="https://github.com/user-attachments/assets/92af463c-1e24-4ee5-91e5-d140e52fd593" />

<!-- drag emoji_before.png and emoji_after.png here -->

### About the fix

The ring moves onto the pill, on `:has(input:focus)`, which is what the neighbouring rule for the magnifier colour already uses in that file.

The two declarations are the pair bootstrap applies in `.form-control:focus` (`forms/_form-control.scss`), so nothing is invented and each flavour keeps deciding through its own variables. Enterprise, with `$input-focus-box-shadow: 0`, shows no ring here just as it shows none for any other input.

For reference this is how the control panel search is assembled, in `addons/web/static/src/search/search_bar/search_bar.xml`: the wrapper carries `form-control` and the input inside it is left plain, so the ring lands on the whole control. Moving `form-control` onto the pill would match that more literally, at the cost of a markup change and of bootstrap's padding and sizing landing on the pill, so the ring is relocated in css instead.

Forward-Port-Of: odoo/odoo#289438

### Steps to Reproduce:
1) Install `website_helpdesk_slides_forum` module
2) On a Helpdesk team, link 2 (or more) forums under `Commnity Forums`.
3) Click on website smart button and then click `Ask the community` button.

### Error:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
KeyError: '_forums'
Template: website_helpdesk_slides_forum.helpdesk_forums
```

### Root Cause:
https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L18-L22

On clicking the "Ask the Community" button calls the `helpdesk_forums`
controller. A single forum redirects straight to it. Several forums get rendered
through `get_template_xml_id()`, with only `forums` in context.

`get_template_xml_id()` is overridden in `WebsiteSlidesForumHelpdesk`,
which points to :

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_slides_forum/views/helpdesk_templates.xml#L3-L5

a primary copy of the inner partial `forum_all_all_entries`. That
partial needs `_forums` (and, once extended by website_slides_forum,
courses_discussions too), both only ever set by the page template's
own t-call:

[Reference](https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/website_forum/views/forum_forum_templates_forum_all.xml#L18-L19)

Since `helpdesk_forums` is rendered directly instead of going through
`website_forum.forum_all`, `_forums` is never set, hence
`KeyError` occurs.

The base `website_helpdesk_forum` module has the same root cause one
level up, surfacing as a different error:

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L24-L25

`website_helpdesk_forum.forum_all` does not exist anywhere in the
codebase. A team with multiple forums, without
`website_helpdesk_slides_forum` installed, hits
```
ValueError: View 'website_helpdesk_forum.forum_all' in website 1 not found
```
Instead of a listing page.

### Fix:
- Both `get_template_xml_id()` implementations now return the real,
  working `website_forum.forum_all` page template, which already sets
  `_forums/courses_discussions` through its own `t-call` and wraps the result in
  website.layout.

- `helpdesk_forums()`'s render values are now built through an overridable
  `_get_helpdesk_forums_render_values()` hook instead of a hardcoded dict,
  so subclasses can extend the context.

- `website_helpdesk_slides_forum` uses that hook to set
  `hide_forum_slides_link=True`, and adds one small non-primary view inheriting
  `website_slides_forum.forum_all_all_entries` that conditions the `/slides` promo
  link (not the "Course" badge, which doesn't navigate anywhere) on `not`
  `hide_forum_slides_link`. This targets the link element itself rather than a
  `t-call` site in `forum_all`, so it correctly applies whether `website_slides_forum`
  groups a given forum as "regular" or "course-linked".

**opw-6332175**

Forward-Port-Of: odoo/enterprise#131734
Forward-Port-Of: odoo/enterprise#124104

Steps to reproduce:
- Install a theme on the current website
- Open the themes kanban ('Switch theme' in the builder, or Website > Configuration > Themes)
- Hover the card of the theme that is installed
- 'Update theme' and 'Remove theme' never show up, the card only opens the live preview

The kanban gates that overlay on `is_installed_on_current_website`, which computes `module == self.env.website.theme_id`. Since [1], `env.website` browses `context['website_id']` and has no fallback.

For every route that is not `website=True`, hence for the `/web/dataset/call_kw` through which the kanban reads its records, `ir.http._match` moves `website_id` into `host_id` and deletes it from the context. `env.website` is therefore always empty there, the field is always `False`, and the template falls back to the preview button.

`button_remove_theme` and `button_refresh_theme` resolve that same empty website. The former hands it to `_theme_remove`, which resets the default config on the generic `website_id=False` scope before returning on its `if not website.theme_id` guard; the latter upgrades an empty recordset and silently does nothing.

Fix by falling back to `host_id`, which `_match` sets to the website the user selected, as `_button_immediate_function` and `button_choose_theme` already do.

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

Issue before this commit:
=========================
The draft progress segment in the manufacturing order Kanban view is barely 
visible against the background.
<img width="442" height="145" alt="image" src="https://github.com/user-attachments/assets/9ba3e4ef-7b91-4c82-86ee-1fe0e47f472f" />


Steps to reproduce:
===================
- Install MRP.
- Create a draft manufacturing order.
- Open the manufacturing orders in the Kanban view.
- Observe the progress bar and notice that the segment representing the
  draft state is barely visible

Cause of the issue:
===================
In this [commit](https://github.com/odoo/odoo/pull/251475/changes#diff-3bad372563263ef117de6ed9e222008e2a27b2ea212df89f72f269066a8eacacR603) the manufacturing order Kanban progress bar was 
changed to represent order states. Draft orders were assigned the `light` color, which 
blends into the Kanban background and makes their segment barely visible.

After this commit:
==================
The progress segment for the draft state is clearly visible, allowing users to
easily distinguish draft orders in the Kanban view.
<img width="343" height="123" alt="image" src="https://github.com/user-attachments/assets/6646143f-a299-4544-b8b5-115e13ebf8c5" />

Forward-Port-Of: odoo/odoo#288925
Forward-Port-Of: odoo/odoo#288462

Toggling "Product Reference Price" in Website Settings never sticks when point_of_sale isn't installed the checkbox appears checked after Save, but reloading the page always shows it unchecked again, with no error.

Reproduce (no point_of_sale installed):
1. Install/keep website_sale without point_of_sale.
2. Go to Website > Configuration > Settings > eCommerce.
3. Check "Product Reference Price" and click Save.
4. Reload the settings page: the box is unchecked again.

Root cause: `website_show_reference_price` (the checkbox) is linked to the global `group_show_uom_price` setting via two onchange methods, and `set_values()` force-disables the website-specific value for every website whenever `group_show_uom_price` is falsy

Fix: keep `group_show_uom_price` in website_sale's own Settings view so its value always round-trips with the rest of the form, independent of whether point_of_sale is installed.

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

Forward-Port-Of: odoo/odoo#288560

Steps:
- Settings > Sales > Enable the 'Line Numbers' setting
- Sales > Quotations > Create a quotation with a few product lines
- Open the Preview and compare it with Print > Quotation / Order

Issue:
- The same quotation shows different column headers depending on where it is
  viewed. On the portal preview the product and quantity columns have no header
  at all, while the PDF labels them 'Description' and 'Quantity'.
  The reverse happens on the line number column, which is labelled '#' on the
  preview but has a blank header on the PDF.

Cause:
- The sale order portal revamp replaced the visible 'Description' and 'Quantity'
  header text with aria-label attributes, but only in the portal template.
  The report template kept its labels. Likewise, the '#' header added for line
  numbering was only added to the portal template and never to the report.

Fix:
- Remove the visible 'Description' and 'Quantity' headers from the report
  template, keeping them as aria-label like on the portal, and add the
  missing '#' header, so the PDF renders the same column headers as the
  preview

Forward-Port-Of: odoo/odoo#288486

Steps to reproduce:
===================
1. Enable Estimated Delivery on a delivery method, lead 1 day, range 90.
2. On the website, add a product to the cart and go to checkout.
3. Pick a date far in the range, then confirm the order.

=> Promised Delivery is the order date + 1 day, not the date picked.

Root cause:
===========
`_set_delivery_method` always writes the earliest offered date on `commitment_date`, and `_recompute_cart` calls it again on the way to payment, so the choice is overwritten just before the order is placed.

- [1] added the date selector with that unconditional write.

Fix:
====
Only fall back to the earliest date when there is none yet, or when the one set is no longer offered, as the checkout already requires.

[1]: https://github.com/odoo/odoo/commit/7e51e356728d24ca0aeb14c5ff94a0eac66e188f 

opw-6538537


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

Forward-Port-Of: odoo/odoo#288271
Forward-Port-Of: odoo/odoo#287236

### Steps to reproduce:

- Install `l10n_tr_nilvera_edispatch` (e.g. the `tr` country build)
- Run `test_basic_stock_flow_with_minimal_access_rights`
> The tour times out on step 6/31, "check that at least one picking is present in the view".

### Cause of the issue:

The step triggers on `.o_stock_list_view_view`, a class the web client derives from the `js_class` of `stock.vpicktree`:
https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/stock/views/stock_picking_views.xml#L66-L70
https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/web/static/src/views/utils.js#L45-L68 `l10n_tr_nilvera_edispatch` overwrites that attribute to plug in its e-Receipt upload button, so the root carries
`o_l10n_tr_edispatch_tree_view` instead and the trigger never matches: https://github.com/odoo/odoo/blob/71c040ae236c9487afc49559486a588f21ccb37b/addons/l10n_tr_nilvera_edispatch/views/stock_picking_views.xml#L4-L13 
Only the class name changes: `L10nTrNilveraEdispatchListView` spreads `StockListView`, so the rendered list is identical.

runbot-947260

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

Forward-Port-Of: odoo/odoo#288404
Forward-Port-Of: odoo/odoo#288255

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#132076
Forward-Port-Of: odoo/enterprise#128430

Issue
=====
When refreshing the page in a opened picking in Barcode and going back, we end up in the picking's form view. It's happen only in debug mode.

How to reproduce
================
1. Enable debug mode;
2. Open Barcode app and open any picking;
3. Refresh the browser's page (F5 on desktop, swap down on mobile);
4. Click on the "<" button to go back on the previous view => Instead of ending back on the picking's kanban view, it opens the current picking's form view.

Cause of the issue
==================
In the `Main` component, the `_exit` method should handle this case by checking if the last breadcrumb action is a number. In such case, we don't use the breadcrumb and use the navigator's usual `history.back` because otherwise, it will open the picking's form view. That said, this code doesn't work in debug mode because it adds `?debug=assets` at the end of the URL, which means when we check if the last part of the breadcrumb's URL is a number — eg. 3 —, instead of get `3`, we get `3?debug=assets`.

Fix
===
To fix the issue, this commit breaks the last part in two in case a `?` is in it and uses the first part only to check if it's a number or not.

Forward-Port-Of: odoo/enterprise#131991

## Issue
Currently, the different options for the approval of a time off (allocation) request are the following:
1. None needed
2. By Time Off Officer
3. By Employee's Approver
4. By Employee's Approver and Time Off Officer

On the Employee's view form, in the Settings tab, the approvers are named:
1. HR Responsible
2. Time Off

The *By Time Off Officer* option does not notify the *Time Off* approver, but the *HR Responsible*, which is not clear for the users. It would be clearer to use a similar naming convention for both the Approvers on the Employee's form and the options for the approval of the time off (allocation) requests.

<img width="1878" height="592" alt="6535827" src="https://github.com/user-attachments/assets/bc7ad9bb-6b53-4553-8fc8-fb305e7c0b28" />

## Steps to reproduce
1. Install *Time Off* (`hr_holidays`)
2. For an Employee E, set an HR Responsible and a (different) Time Off approvers
3. Create a Time Off request for the Employee E
    - Ensure that the selected Time Off Type has its approval method set to "By Time Off Officer"
4. **The user notified off the time off request is the HR Responsible, which is unexpected, considering that we expect an approval from the "Time Off Officer".**

## Justification
In the `_get_responsible_for_approval` method, when using the "By Time Off Officer" option (`'hr'`), it is clearly the `hr_responsible_id` (HR Responsible) who is selected as "responsible" for the approval.

https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave.py#L1557-L1559

The exact same logic is applied for the allocation requests [here](https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave_allocation.py#L1070-L1072).

## Targeted version
We are targeting version 19.2, as it is the version from which the `responsible_ids` field (which was clearly specifying who had to be notified for the approval of a time off request) was removed (see https://github.com/odoo/odoo/commit/d37cf89a6ff134988b4a7c001a97973cd95a2ea8).

If deemed interesting, the same modification can be backported to previous versions too.

opw-6535827

Forward-Port-Of: odoo/odoo#288890
Forward-Port-Of: odoo/odoo#287686

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

Forward-Port-Of: odoo/odoo#287464

### Issue:
On iPhone and iPad (reduced window), the scrollbar is hidden behind the report on long scrollable pages
This affects all browsers on iOS and iPadOS — Apple forces the use of WebKit (its rendering engine) on all of them, including Chrome and Firefox

### Steps to reproduce (on iPhone):
- Install `l10n_es` (contains scrollable reports by default)
- Switch to the ES company
- Open the Tax Report and try to scroll
 
Before the fix, the scrollbar renders behind the report content

### Cause:
`o_content` was added unconditionally in commit https://github.com/odoo/enterprise/commit/d60ea6e0f3245e394fd0cee5f22f52aff2a79e2e
But its role differs between desktop and mobile, and its presence on mobile triggers a WebKit compositor bug

On desktop, `o_content` is required:
`.o_action` stays `overflow: hidden`, so only `.o_content` (`overflow: auto`) can scroll the report
Per the CSS flexbox spec, a flex item won't shrink below its content size unless its `overflow` is not `visible`
Without `o_content`, the div keeps `overflow: visible`, refuses to shrink, overflows `.o_action`, and the excess is silently clipped — content becomes unreachable, not just visually different

On mobile, the framework flips scroll responsibility to `.o_action` (`overflow: auto`) and forces `.o_content` back to `overflow: initial`
`o_content` is therefore not needed on mobile

On WebKit (iOS/iPadOS), keeping `o_content` on mobile is harmful: it sits as a non-scrolling `position: relative` node between the real scroll ancestor (`.o_action`) and descendants that require special compositing — the sticky `thead` and the fixed-position mobile chatter
This configuration causes WebKit's compositor to miscalculate the Root layer bounding box
This geometry mismatch is the most likely explanation for why the native scroll indicator renders behind the report instead of on top of it
Removing `o_content` on mobile avoids this node entirely and restores correct compositor geometry

### Notes:
Tested on Android (Blink) with and without `o_content`: no visual difference and identical compositor layer geometry confirmed via Chrome DevTools — no regression introduced

The `padding-bottom` on `.o_account_report_scroll_container` is unrelated — it is applied unconditionally and exists for a separate bug (last row clipped on scroll)

opw-6191827

Forward-Port-Of: odoo/enterprise#132241
Forward-Port-Of: odoo/enterprise#128528

**Steps to reproduce:**
1. Upload a vendor bill with OCR digitization (pdf in ticket attachments)
2. Make sure the Bill Date field already has a value
3. Click into the Bill Date field so the OCR boxes appear on the attachment preview
4. Click on a different date box in the attachment to correct the value

**Issue:**
The field is not updated with the clicked box's value. Instead, the field simply loses focus and the OCR boxes disappear, as if the user had clicked outside the field. This only happens when the date field already has a value; it works fine when the field is empty.

**Cause:**
- When a date field has a value, the date widget renders it as a button and only swaps in the real `<input>` once focused [1]
- Removing the button triggers `onBlurFieldWidget`, and when the datepicker is focused, it triggers `onFocusFieldWidget` once again:
https://github.com/odoo/odoo/blob/89650a5f44b5835028dba57a9ff6fa30515bc5ec/addons/web/static/src/views/fields/datetime/datetime_field.js#L204-L214
- The datetime picker's popover uses `useClickAway`, which reacts to `pointerdown` on `window` to detect clicks outside itself and close the popover.
- Clicking a box in the attachment preview is therefore caught by this listener before anything else: it closes the popover, removing the currently focused DOM node and firing a `focusout`.
- `ExtractMixinFormRenderer` reacted to that `focusout` by resetting the active field and destroying the box overlay. Since the box's own value-selection ran on `click`, the last event in the `pointerdown → mousedown → mouseup → click` sequence, the reset had already been done, so the click was lost.

**Fix:**
- Apply the box's selection on `pointerdown` instead of `click`, so it runs synchronously in the same event dispatch that triggers the popover's close logic, guaranteeing it executes before any asynchronous re-render can remove the field's state.
- Remove the legacy `pointerdown` listener in `ExtractMixinFormRenderer.`. Because our box now listens to `pointerdown`, it was intercepting the event and breaking selection for images

[1] - https://github.com/odoo/odoo/pull/218387

opw-6511803

Forward-Port-Of: odoo/enterprise#131935
Forward-Port-Of: odoo/enterprise#130192

Issue Before This Commit:
========================
Currently, when a product variant has multiple UoMs, those UoMs 
appear for all variants when selecting a product in a Sale Order Line,
even though they are only available for a specific variant.

Steps to Reproduce:
=========================
1: Install the sale and sale_management modules.
2: Enable Units of Measure and Packagings.
3: Create two variants, V1 and V2, and set an Extra Packaging of 'Pack of 6' on V2.
4: Add the product to a Sale Order Line. A product configuration wizard will open.
5: Select V2. The Unit and 'Pack of 6' UoMs are correctly displayed.
6: Select V1. Both UoMs are still displayed, even though 'Pack of 6' is not available for V1.

Cause of the issue:
=========================
When the variant is changed to V2 in the wizard, _get_basic_product_information is 
called. At that point, the condition is true, so available_uoms is updated with the UoMs available for V2.

However, when the variant is changed back from V2 to V1, the method is called again, 
but V1 does not have multiple UoMs. Therefore, product_or_template._has_multiple_uoms()
returns False, and available_uoms is not updated.

As a result, the UoMs from V2 remain in available_uoms and are incorrectly displayed for V1.

After This Commit:
========================
Update _get_basic_product_information to ensure that the available UoMs are updated
whenever the variant changes. This ensures that only the UoMs available for the 
selected variant are displayed.

Forward-Port-Of: odoo/odoo#289160
Forward-Port-Of: odoo/odoo#288515

Step to reproduce:
- install `pos_sale`
- create a pos and go to settings
- remove product from `Default Sale Product`
- start pos and select a product

Observation:
- we will get a blank screen and error in browser console
```
TypeError: Cannot read properties of undefined (reading 'id')
    at get orderDisplayProductName (point_of_sale.assets_prod.min.js:20914:497)
    at get orderDisplayProductName (point_of_sale.assets_prod.min.js:27593:14)
```
- similar case when we de-select downpayment product and load a SO
with downpayment

Cause:
- `default_product_id` was introduce in commit[1] which is necessary for
description first order line
- if we remove this field, for pos config, `this.config.default_product_id`
is undefined, and accessing its id raises error
[1] https://github.com/odoo/odoo/commit/0ce605f8db9aa9901bf6b14c4888e5bcc0734401

Fix:
- Made both fields required=True, and removed the now-redundant JS-side
  guards that previously enforced this on the client.
- Both fields use a callable `default=` that resolves an xmlid created in
  pos_sale_data.xml. During module init, ORM invokes this default to
  backfill existing rows *before* data files are loaded, so it resolves to
  `None`, leaving rows null and causing the NOT NULL constraint to fail.
- Added `_init_column_default_products` (via `init_storage`) to create
  minimal placeholder products and register their xmlids ahead of the
  constraint check, so the default resolves correctly on first init.
  `pos_sale_data.xml` still loads afterward and updates these same records
- With this in place, the previous `post_init_hook` backfill is no longer
  needed and has been removed.

Why not adding a upgrade script
- when creeating the new column, as we have defined a `default` property for both fields, they are populated.
- in case a db is missing the xml id for such products, they are re-created and populated again.
- so there is no chance, we will face any error during upgrade. 

opw-6458117

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

Forward-Port-Of: odoo/odoo#282002

*= sale_purchase_inter_company_rules

Step to reproduce:
- install `sale_purchase_stock_inter_company_rules` and pos with demo
- from setting :
       - enable Multi-Step Routes
       - enable all options for Inter-Company Transactions (for both companies)
- go to routes, un-archive MTO route
- create a product "A" with routes "MTO" and "buy"
- make the product available for pos (add into `Misc` category)
- create a attribute with custom attribute value and link it to "A"
- in vendor list, add "My Company (Chicago)" as vendor
- switch to Chicago company,  for same product add some other vendor
- switch back to "My Company (San Francisco)"
- for pos, in setting enable "Allow Ship Later"
- open Furniture pos, create a order with Product "A"
- go to payment page and select "Ship Later" and pay
- a RFQ is created for this pos order, open and confirm it
- switch to "My Company (Chicago)"
- open sale order (remove "my quotation" filter)
- notice a quotation created from company 1, confirm it.
- open linked delivery slip

Observation:
- the delivery slip will not have description (custom value for attribute for A
is lost)

Cause:
- when preparing vals for SO for inter-company transaction from
`_prepare_sale_order_line_data` we never considered order from pos
- hence in this case, order lines never had custom attributed linked to them
- the description is computed from the attributes from SO
- SO never had them to begin with

Fix
- we introduced a method `_get_pcavs_from_pos_order` which fetch such attributes from pos order too
- to accomplish this we introduce a new module  As there is no dependency with purchase and pos

opw-6213076

Forward-Port-Of: odoo/enterprise#131896
Forward-Port-Of: odoo/enterprise#119233

## [FIX] l10n_co_reports: fix UNION ALL crash with multiple column groups

### Issue:
Any comparison mode (Period, Analytic, etc.) in the Libro Diario raises an Odoo Server Error

### Cause:
Each sub-query in the `UNION ALL` had its own `ORDER BY` SQL only allows one global `ORDER BY` on a `UNION ALL`, or parentheses around each query — neither was the case

### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Enable Developer Mode in Settings
- Open the Libro Diario report and click the gear icon (top right)
- In the Options tab, enable Period Comparison
- Enable the Comparison for the Previous Period

Before the fix, an error is raised

------------------------------

## [FIX] l10n_co_reports: include partnerless entries in Libro Diario

### Issue:
Journal entries without a partner are excluded from the report but are legally required to appear

### Cause:
`_get_domain` called `super()` which adds `('partner_id', '!=', False)` to the domain, filtering out all partnerless entries
The SQL query also used a `JOIN` instead of `LEFT JOIN` on `res_partner`, excluding lines with no partner at the DB level

### Notes:
`NULL` values for `partner_name` or `line_label` caused the JS to hide the corresponding column headers
`header.js` matches columns to their header by `column_group_index`/`expression_label` and skips `None` values
Fixed by using `COALESCE` to return an empty string instead

### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Create a Journal Entry without a partner or label
- Open the Daily Journal Report

Before the fix, the entry doesn't appear
After the fix, check that PARTNER and LABEL headers are visible

opw-6430728

Forward-Port-Of: odoo/enterprise#132066
Forward-Port-Of: odoo/enterprise#129674

## Summary
- Grabbing an already-connected output port and dragging it to a new target used to search for another output port instead of an input port, so the old connector was removed without ever being replaced.
- Dropping a new connection onto an output port that was already at its connection limit was rejected outright instead of replacing the existing connection.
- A successful reconnect could still show "This connection already exists.": `onConnect` feeds the new connection back through props synchronously, and `onWillUpdateProps` can sync it into the store before `connectPorts`'s own post-connect validation runs, making the connection look like a duplicate of itself.

## Test plan
- [ ] Open a call flow, connect an output port to a target, then drag that same output port to a different target: the old link is removed and the new one is created in one action.
- [ ] Drag a new connection onto an output port that already has one: the old link is replaced instead of showing a rejection.
- [ ] Confirm no "This connection already exists." notification appears for a valid reconnect.

Forward-Port-Of: odoo/enterprise#131942

**Issue**
The height is not correctly computed in the picking form when editing product description.

**Steps to reproduce**
- Create a delivery for a product
- Add a description to it
- Click on editing the description
 -> Observe that the description is partially hidden because the widget height is incorrectly computed

**Cause**
Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root.

The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`:
https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 
**Solution**
Explicitly add a div around the product display and description to still use the `Autoresize`

Forward-Port-Of: odoo/odoo#280243
Forward-Port-Of: odoo/odoo#271564