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

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

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

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

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