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

# How to reproduce
- Create the following categories :
	- Category A
		- Category B, Child of Category A
	- Category X
		- Category Y, Child of Category X
		- Category Z, Child of Category X
- Create a published product for category B & Z
- Go to the Shop page
- Enable the Sidebar Categories
- Log out
- Go to the Shop page

# The issue
The link for the Category Z is broken and clicking the Category does nothing.

# Cause
When rendering the recursive template for the categories : https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website_sale/templates/shop_page_templates.xml#L1291 https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website_sale/templates/shop_page_templates.xml#L1310

The rendering engine will fetch the values for the `website_url` field for every `child_id` of every Category because of the prefetch mechanism, even the one public users dont have access to : https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/addons/website_sale/security/ir.access.csv#L16

During the compute of that field, the records will be ordered in this way :

1) Category B => User has read access
2) Category Y => User does NOT have read access, because no product 
3) Category Z => User has read access

So an access error will be raised here for the 2nd Category : https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/addons/website_sale/models/product_public_category.py#L149

Which will be intercepted by the fallback of the getter, that retries the compute with only the first record. This will succeed because the user has access to that record :
https://github.com/odoo/odoo/blob/ceae1f02580601bf179fc36e449112a88c3dff8d/odoo/orm/fields.py#L1827-L1828

The issue is that the call to `super()` at the start of the compute already assigned a value to all the records, so all Categories have a value in the cache for `website_url`, even after the fail of the compute :
https://github.com/odoo/odoo/blob/8cefaf36e2b4ce6db869dba63874c933060b702b/addons/website/models/mixins.py#L255-L258

So when trying to access Category's Z `website_url`, we'll get '#', without any recomputation being done because of the cache value

opw-6481175

[FIX] ai_website: save custom css scoped

Before this commit, if you had multiple websites, AI wouldn't save
custom css in the correct website's bundles, which caused the following
broken flow:
- open css editor, make any changes, and save it
- open the AI website builder agent and ask it to make all buttons red,
  writing a custom css for that

=> you get a traceback, and after reloading your website is broken.

Note that this isn't an issue in 20.0 as this behavior has been changed.

Related to task-6578231

---

 [FIX] ai_website: validate custom SCSS with bundle url rewriting

When AI used url($var) in scss, it would break the style compilation and
display an error. This happened because compiling replaced relative urls
with the absolute path. It wasn't caught before saving the custom css,
because we preprocessed css content inline, which doesn't rewrite
relative url()s.

To directly check it, you can just ask it to save this custom css:
`'$img: "a.png"; #test { background: url($img); }'`
=> Style compilation will fail.

Also, this commit updates some already present nested `with` statements
in tests to remove Ruff warnings.

task-6578231

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

#### Issue:
When creating a reordering rule for a shared manufactured product in a multi-company database,
saving the rule may raise an `AccessError` on `mrp.bom`.

The orderpoint is still created, but the user sees a record-rule error if the product also
has BoMs in companies that are not currently active.

#### Example:
A product is shared across multiple companies, and each company has its own BoM for that product.
In the reproduced case, the active company has the correct variant BoM.
However, the orderpoint computation first checks the broader product-template BoM relation,
which may include BoMs from the other companies. As a result, Odoo can try to access
a BoM from another company while the user is only working in the active company,
causing an access error.

#### Steps to reproduce:
Use a multi-company database with MRP enabled.
Create or use a shared product available to multiple companies. Create BoMs for that product in more than one company. Set the active company to the company where the reordering rule should be created.
Create a reordering rule for the product.
Save the reordering rule.
Note the AccessError related to mrp.bom.

#### Root Cause:
The MRP orderpoint computations read `product_id.bom_ids` directly. This is the product-template BoM relation and can include BoMs from other companies for a shared product. Reading fields on those BoMs, such as `product_uom_id`, can hit the standard `mrp.bom` multi-company record rule.

#### Fix:
Prefer `product_id.variant_bom_ids` before falling back to `product_id.bom_ids` in the affected orderpoint computations. This avoids reading template-level BoMs from other companies when the product has a variant-specific BoM for the current reordering-rule use case.

opw-6253743

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

Forward-Port-Of: odoo/odoo#278936
Forward-Port-Of: odoo/odoo#267411

Editing the notes of a booking from the POS gantt view raised an error when saving the field.

**Step to reproduce:** https://app.tango.us/app/workflow/Create-Booking-in-Bookings-App-b045c76169c8432b8516c6bbd0f366e6

> TypeError: ids is not iterable (cannot read property undefined)
    at Object.addPendingAttachments (https://125652949-saas-19-4-all.runbot316.odoo.com/web/assets/fb4fcbe/point_of_sale.assets_prod.min.js:25792:32)
    at HtmlField._commitChanges (https://125652949-saas-19-4-all.runbot316.odoo.com/web/assets/fb4fcbe/point_of_sale.assets_prod.min.js:25759:104)

The POS HTML field uses a reduced set of editor plugins that does not include the MediaPlugin. Since the booking notes field relies on the same HTML field, extracting the pending attachment ids returns undefined instead of an empty array.

This undefined value is then passed to `addPendingAttachments`, which expects an iterable and raises a TypeError.

To avoid this, wrap `addPendingAttachments` in the POS appointment HTML field setup and only call the original method when attachment ids are available.

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

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

## Steps to Reproduce:
- Install the Subscriptions module with demo data.
- Create a quotation containing a subscription product.
- Set a recurring plan and confirm the quotation.
- Create an upsell quotation or a renewal quotation.
- Cancel the original subscription.
- Remove the recurring plan from the cancelled subscription.
- Open either the upsell or renewal quotation and confirm it.

## Error:
`TypeError - '>=' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
Since Commit https://github.com/odoo/enterprise/commit/315be581a4212b46191e0c4f82b02a2c3fde51dc#diff-07cf1dda5423f99452a763a54fb6e7fdbb861e19b1a9dca00cab093a832490a9, `plan_id` is no longer required when a subscription is in the cancelled state.

During the confirmation of an upsell or renewal quotation, the parent subscription's next invoice date is used for several date validations. However, if the parent subscription is cancelled and its plan is removed, the `next_invoice_date` is computed as False. Comparing a date object with a boolean value leads to an error.

## Fix:
This commit adds an extra check before using the next invoice date.

sentry-7661150764

Forward-Port-Of: odoo/enterprise#131808
Forward-Port-Of: odoo/enterprise#128093