**Steps to reproduce:**
1. Install the *Fleet* and `accounting` modules.
2. Create a new purchase tax.
3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund.
4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines.
5. Check the *Tax Report*(account>tax), including the date of this vendor bill.

**Observed behavior:**
* Tax lines linked to the current asset account are merged.
* Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`).
* This mismatch triggers an error in the tax report.

**Root cause:**
The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles.

**Solution:**
Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error.

opw-5013757

Forward-Port-Of: odoo/odoo#232001
Forward-Port-Of: odoo/odoo#228422

Steps to Reproduce:
- Create a Sale Order containing two combo products placed consecutively.
- Change the quantity of the first combo → corresponding combo items update correctly.
- Without saving, change the quantity of the second combo.
- Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo.

Issue:
- The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order.

Cause:
- During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition.
- Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping.
- This causes combo items to shift relative to their parent combo lines.

Solution:
- Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence.
- This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated.

opw-5148770
Affected Version:18.0

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

Forward-Port-Of: odoo/odoo#233740

[FIX] website: get scroll from document element for footer animation

__Current behavior before commit:__
Since [this PR], the scrolling is not done on `#wrapwrap` anymore.
Now when an animation is set on an element inside the footer it
will not appear if a slideout effect is set on it.

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Click on a column in the footer.
3. Set an "On Appearance" Animation on it.
4. Set the footer Slideout Effect to "Slide Hover".
5. Add some content on the page so that it's needed to scroll for the
footer to be visible.
6. Save.
7. Scroll to the footer.
=> The column doesn't appear.

[this PR]: https://github.com/odoo/odoo/pull/98429

---

[FIX] website: scroll on new entry in faq horizontal

__Current behavior before commit:__
Since [this PR][1], the scrolling is not done on `#wrapwrap` anymore.
Now when adding a new entry to the snippet faq horizontal, the page
doesn't scroll automatically to the new entry.

This behavior has actually never worked because [the PR that introduced
faq horizontal][2] was merged just after [the PR that moved the
scrolling to the document element][1]. 

__Description of the fix:__
Get `scrollTop` and `scrollHeight` from the document element instead of
`#wrapwrap` and add a test tour.

__Steps to reproduce:__
1. Open the Website builder.
2. Drag a Text block
3. Choose the FAQ horizontal snippet
4. Click on "Add New"
=> The page doesn't scroll to the new entry.

[1]: https://github.com/odoo/odoo/pull/98429
[2]: https://github.com/odoo/odoo/pull/176438

Forward-Port-Of: odoo/odoo#233911
Forward-Port-Of: odoo/odoo#228396

### Issue:

Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors.

### Steps to reproduce:

- In the settings enable "Batch Transfers"
- Inventory/Operations/Transfers/Batch Transfers
- Create a new batch and do not confirm it
- Go to the barcode app > Batch Transfers > Clear filters
- Select your draft batch
- Scan anything
#### > Traceback

#### Other issues:

The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done".

### Cause of the issue:

Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error:
https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179

opw-5162164

Forward-Port-Of: odoo/enterprise#98022
Forward-Port-Of: odoo/enterprise#97526

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

```
  File /home/odoo/src/odoo/saas-18.4/addons/website_sale_product_feed/models/product_feed.py, line 105, in _check_product_limit
    raise ValidationError(feed.env._(
odoo.exceptions.ValidationError: A single feed cannot contain more than 5,000 products. Please separate products with Categories.
```
```
(Pdb) feed.env['product.product'].search_count(feed._get_feed_product_domain())
12433
```
During migration I am getting the traceback mentioned above, which is occurring because [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/__init__.py#L14) we have populated feed records in _post_init_hook which will create feed records without any [category ID](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/website.py#L21) because of which, [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/product_feed.py#L101) we get all records without a category, which is of course higher than our soft limit of 5000, and a validation error occurs: the customer database does not have GMC enabled. Still, it calls _populate_product_feeds, which is why I have moved it to a condition.

opw-5180407

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

Forward-Port-Of: odoo/odoo#233365

### Issue:
Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled.

This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list.

`companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3.

### Solution:
A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies.  Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed.

opw-4880477

Forward-Port-Of: odoo/odoo#229829
Forward-Port-Of: odoo/odoo#217001

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged.

Cause:
- The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns.

Fix Applied:
- Updated frontend (`filters.js`) to call `format_column_values_from_client` via
  `dispatch_report_action` instead of calling `format_column_values` directly.
  (this enables proper routing through the custom handler system)
- Added `format_column_values_from_client` override in `JournalReportCustomHandler`
  that intercepts the formatting call and applies special handling for tax summary
  lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines`
  monetary fields using their `_no_format` counterparts.
- The custom handler then delegates to the base method via
  `report.format_column_values_from_client()` to format standard columns.
- Also added missing `_no_format` fields in `account_journal_report.py` for
  `base_amount` and `tax_amount` to enable proper reformatting.

Forward-Port-Of: odoo/enterprise#98641
Forward-Port-Of: odoo/enterprise#94660