Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed.

Problem 1: If ZATCA does not properly receive the invoice generated
from a POS order (wrong onboarding, wrong details on company, etc.)
the invoice printed from POS will not contain the QR code, even after
successfully resubmitting the invoice to ZATCA, load the order and 
reprint the invoice to see this

Testing the fix: Change the VAT number on the company to be faulty, 
create a POS order, Fix the VAT number and resubmit the invoice, load
the POS order and reprint invoice, it will now show the QR code.

Problem 2: When disabling the E-invoicing for a phase 2 journal,
the POS receipt will still try to print the phase 2 QR code but the system
will flag it as 'not legal' leaving the POS receipt empty, when it should
instead print the phase 1 QR code

Testing the fix: On the journal, disable the E-invoicing, and create a POS
order, it will now show the phase 1 QR code on the receipt

task-5032474

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

Forward-Port-Of: odoo/odoo#243984
Forward-Port-Of: odoo/odoo#234945

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

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

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#246147
Forward-Port-Of: odoo/odoo#241086

_______________________________________
## Short functional explanation of the error
Let's say we have a products that has 2 suppliers. In the list of suppliers, the first one set has an expired date. If we generate a PO from an SO with the MTO route, the assigned supplier for this product will be the first one set in the list, therefore having an expired date.

## Reproduction Steps
1. Go to Inventory > Configuration > settings. Check the option Multi-Step routes.
2. Click on Configuration > routes and unarchive the Replenish On Order (MTO) route.
3. Create or use an already existing product. Go to the Inventory tab, and under Operations, check the routes Replenish on Order (MTO) and Buy.
4. Click on the Purchase tab. There, set a first vendor for which the end date is earlier than today. For the second one, set an end date for which the date is later than today.
5. Go to Sales and create a new quotation. Set a customer and add a line with the product you just set. Click confirm. A smart button 'Purchase' should appear. Click on it.

### Expected behavior
The assigned vendor of the PO should be the second vendor as it isn't expired yet.

### Unexpected behavior
The assigned vendor is the first vendor, expired.

## Origin of the issue
When generating a PO from an SO, the partner is the person ordering the product, not the vendor. Therefore, when this code is executed:

https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L62-L66

no corresponding supplier is found, as
```self._get_partner_id(procurement.values, rule)``` returns the customer
and not the vendor. This leads us to the fallback:
https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L68-L72
which doesn't take into account the end date of vendors.

__
opw-5030849

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#245313
Forward-Port-Of: odoo/odoo#225684