**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246699
Forward-Port-Of: odoo/odoo#246084

**Problem:**
when there is multiple pages for the avco reports
the total value and quantity are not correctly computed

**Steps to reproduce:**
- create an avco storable product with a cost of 10
- create and validate 3 in moves for a quantiy of 1 each
- navigate to Inventory/ Stock and search your product
- click on the unit cost
- (see how the total quantity is 3 and total value is 30)
- change the view to display only the first 2 records
(write 1-2/4 on the top write)

**Current behavior:**
the total quantity is now 2 and total value 20

**Expected behavior:**
it should still be 3 and 30

**Cause of the issue:**
inside _compute_cumulative_fields, we start with a 
total_value and total_quantity of 0, then those variables 
are increased or decreased by each record in records
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L94-L104
but records is computed based on self which contains
the lines displayed on the view
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L91

**fix**
I need to add an if statement to avoid writing on the records
not displayed on the view because this causes an access_error

opw-5421925

Forward-Port-Of: odoo/odoo#244070

### Steps to reproduce:

- In the settings enable: Batch, Wave & Cluster transfers
- Inventory > Configuration > > Warehouse Management > Operation types
- Enable Auto-batches, Batch grouping by partner on Delivery orders
- Create and confirm a delivery for 2 units of a storable product that you do not have in stock.
- Change the quantity of the move to 1 unit
#### > The delivery is not auto-batched

### Expected behavior:

As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver.

### Cause of the issue:

The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow:
First at confirmation:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`.

opw-5441718

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

Forward-Port-Of: odoo/odoo#246164
Forward-Port-Of: odoo/odoo#245542

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#244758
Forward-Port-Of: odoo/odoo#238989

Current behavior:
When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the last selected attribute value is kept in the URL of the pager.

This happens because the `/shop` controller processes query parameters using a standard Python dictionary (**post). Since a dictionary cannot hold duplicate keys, an URL like `?attrib=1&attrib=2` is reduced to `{'attrib': '2'}`, losing all previous values.

Steps to reproduce:
1. Install `website_sale`.
2. Reduce "Products per Page" (e.g., to 4) to easily trigger pagination.
3. Go to the /shop page.
4. Select a first attribute (e.g., Color: White).
5. Select a second attribute (e.g., Size: M).
6. Ensure the result spans at least two pages.
7. Click on page "2".
8. Observation: The second attribute filter is lost, and the product list changes incorrectly.

Fix:
Ensure that `attribute_values` are stored as a list within the `url_args` passed to the pager. Since Odoo's `website.pager` uses `url_encode` internally, passing a list of values for a single key correctly generates repeated parameters in the resulting URL (e.g., `attrib=1&attrib=2`).

opw-4152637

Forward-Port-Of: odoo/odoo#245784
Forward-Port-Of: odoo/odoo#244941

Before this commit, the channel member actions were hard to find:
- Click on Members panel.
- Click on Member to open popover card.
- Click on "..." in top-right corner of card.

This is hard because only this avatar card from this menu has the "..." button, and the actions are hidden in this menu. This is easy to miss since avatar cards in message list or other places don't have this "...", and since the actions are hidden there many people could easily miss these actions.

This commit improves the visibility of action by their showing as a "..." on the member item on hover in the "Members" panel. This works like the "..." button in the discuss left sidebar, where the button is shown on mouse-hover. Mobile view (small or mobile device) shows the button all the time next to member, making the discoverability of the action very clear.

Task-5871730

Before / After
<img width="589" height="385" alt="Screenshot 2026-01-23 at 14 45 17" src="https://github.com/user-attachments/assets/bca66975-13cd-423a-a43d-9eb2be03741a" />
<img width="249" height="270" alt="Screenshot 2026-01-26 at 11 56 09" src="https://github.com/user-attachments/assets/edfe34c9-6b4c-4394-b532-7f79f9653b4a" />


----

This PR also makes channel member actions available in guest items, so we can now "Remove Member" on guests too.

<img width="252" height="296" alt="Screenshot 2026-01-27 at 18 25 54" src="https://github.com/user-attachments/assets/ee4b1271-0529-4e96-bda1-e621d7592555" />

Description of the issue/feature this PR addresses:

Fixes timer not showing to participants of a live session after submitting an answer.

Current behavior before PR:

Steps to reproduce:

Create a Survey with two questions of any type.
Set some Question Time Limit on both.
Create Live Session for that Survey.
Access Live Session as a participant.
Start Survey as the host.
The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question.
Bug: timer for the second question does not appear to the participant.

Desired behavior after PR is merged:

Fix:
The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function.
Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function.
This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress`
and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'`
Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received.

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

Forward-Port-Of: odoo/odoo#246789
Forward-Port-Of: odoo/odoo#241086