After a recent change, the smart button for Source POs uses the reference_ids on a stock.picking. This altered the logic to fetch all orders from any picking that has the same reference. However, `subcontracting_source_purchase_count` should specifically relate to the resupply of subcontractor picking to their subcontracted purchase order.

**Steps to Reproduce:**
1. Enable multi-step routes and subcontracting
2. Unarchive the MTO route
3. Create 4 products Finished Product, A, B, C, and set MTO on both A and B
4. Put 10 units of C in stock
5. Create a BoM for Finished Product using A and B as components
6. Create a subcontracted BoM for B using C as a component
7. Set the purchase vendor for product A as the vendor
8. Set the purchase vendor for product B as the subcontractor
9. Create and confirm a manufacturing order for Finished Product
10. Confirm the POs

The two POs are:
1. Purchase Product A from its vendor
2. Subcontract Product B from its subcontractor and use Product C as a component

**Current Functionality:**
- Product A's receipt has a **Source PO** smart button pointing to the subcontracting PO for Product B (BUG)
- Product B's receipt has a **Source PO** smart button pointing to its own PO (BUG)
- Product C's picking has a **Source PO** smart button pointing to its own PO

**New functionality:**
- Product A's receipt has no **Source PO** smart button
- Product B's receipt has no **Source PO** smart button
- Product C's receipt has a **Source PO** smart button pointing to its own PO

opw-6420168

Forward-Port-Of: odoo/odoo#278908

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

When moving a document into a folder (e.g., via drag and drop), the
document fails to inherit the group access rights defined on the
destination folder if that folder does not have an owner. While direct
uploads correctly apply the groups, moved documents only inherit
partner access rights in this scenario, potentially leaving group
members without the expected access.

This occurs because group access rules were inadvertently filtered out
during the rights sync when the system evaluated the missing folder owner.

This commit ensures that group-based access rules are correctly
retained and applied to the document when it is moved into a folder,
regardless of whether the destination folder has an owner.

Steps to reproduce:
- Create a new folder and ensure the "Owner" field is empty.
- Add a group to the folder's access rights.
- Drag and drop a file from elsewhere into that folder.
- Notice the document doesn't inherit the group from the parent folder.

Task-6585315

Forward-Port-Of: odoo/enterprise#132235

# 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

Issue:
-------------------------------------
When creating a vendor bill, the Purchase Order Line field on the bill line
allows selecting a purchase order line. However, the search only matches the
POL name and does not allow searching by the purchase order name.

Steps to reproduce:
-------------------------------------
1. Install the `purchase` module.
2. Go to Vendor Bills, click New, and select a vendor.
3. Add the Purchase Order field to the bill line using the optional fields.
4. Click Add a line and open the Purchase Order selection.
5. Try to search for the line using the purchase order name.
The purchase order line cannot be found.

Cause of the issue:
-------------------------------------
The `purchase.order.line` model does not define `_rec_names_search`,
so the record search only considers the purchase order line's `name` field.

Solution:
-------------------------------------
Define `_rec_names_search` with both `name` and `order_id` so that POLs
can also be searched using their related purchase order name.

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

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

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.

Steps to produce:
----
- Install sales and studio module.
- Create new product and make sale order using it.
- Confirm the sale order and open the studio.
- Click on sale order line > Click on edit list view.

Issue:
---
- Clicking the `edit list view` button raises a traceback:
  `TypeError: Cannot read properties of undefined (reading 'locked')`

Root cause:
---
- The issue was introduced by [commit].
- `saleProductMixin.hasConfigurationButton` reads the parent sale order's
  `locked` field by walking up the model tree:

https://github.com/odoo/odoo/blob/973218b9d60ebe715f0bf5a9bdc54b036b002e9b/addons/sale/static/src/js/sale_product_mixin.js#L68

- This works in a normal form view because `model.root` is the sale order
  Record, and Record always has a `.data` object containing its field values.

- In Studio's list editor, `model.root` is no longer the sale order Record.
  Studio replaces it with a `StaticList` - the list of order lines itself.
  so, it can render the `subview` directly:

https://github.com/odoo/enterprise/blob/a6c971daad566043e073b2cb6f2fd18794b49fb0/web_studio/static/src/client_action/view_editor/editors/list/list_editor.js#L73-L77

- `StaticList` holds a collection of child records. It has no field values
  of its own, so it never sets .data. Accessing `model.root.data`
  returns undefined.

Solution:
---
- The `locked` check is only meaningful when a full sale order record tree
  exists above the line, which isn't guaranteed for every rendering
  context. Falling back to `undefined` when `root.data` is absent keeps
  the check inert rather than crashing,
  without changing behavior in the normal runtime path where `root.data`
  is always a valid `Record`.

[commit]: https://github.com/odoo/odoo/commit/84f4c84adfba546ba940175411363a865d8f7c3a

opw-6566217
---
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#287351
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

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