Description of the issue/feature this PR addresses:
On the AFIP portal, there are specific tax values and scenarios when registering purchase invoices that are not currently supported by the l10n_ar module.

Desired behavior after PR is merged:
This improvement adds the required tax accounts and definitions for Argentina localization. It ensures legal compliance and proper fiscal reporting for companies using l10n_ar.

Key changes:

Added new tax account templates for various Argentine tax scenarios, including “Otros Impuestos” and “Impuestos Internos”.

Updated and extended tax definitions to align with AFIP and ARCA requirements.

Improved mapping between tax codes and accounts for accurate reporting.

These changes make it easier for users to configure and use Odoo with accurate fiscal settings for Argentina, reducing the risk of accounting errors and improving compliance with local regulations.



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

Issue:
----------------------------------
When accessing a work order in a work center not included in the default
selection on the shop floor, the system would change the default view by
removing `All MO` and `My WO`, disrupting the expected behavior for users.

Steps to reproduce:
----------------------------------
- Open the Shop Floor view and note the default filters like All MO and My WO.
- Access a production whose work order is in a work center not included in the
  current selection, and move it to that work center.
- Observe that the view reloads and the default filters are removed, showing
  only the newly added work center.

With this commit:
----------------------------------
The function is fixed to keep default selections like All MO and My WO when
adding a new work center. These were previously removed because they aren't
stored and weren't re-added. Now, the new work center is added without altering
the default view.

Task-id: [4392236](https://www.odoo.com/odoo/project/966/tasks/4392236)

The link between purchase order and a repair order break at when the PO is confirmed.

### Steps to reproduce:
* Install the Repair and Purchase modules
* Activate multi-steps routes
* Unarchive the MTO route
* Create a product with the MTO route enabled
* Create a Repair
* On the Repair Order, in part add:
	- type : ADD
	- product : mto product
* Save the RO
* Go to Purchase Order
* Confirm the PO
-> Issue Smart link between PO and RO broken.

### Observation:
The smart link is defined on:
RO -> PO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17

When we confirm the PO, from the picking information it will create new moves:
https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298

To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365

### Origin:
In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5:
"`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`."
This breaks the link between PO <-> RO to maybe merge the move in the future.

This issue is not present in 19.0 since it was solve in this commit :
https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a

### About the fix:
The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location.

opw-5121816

### **Summary**

In a real multi-company setup with multiple Belgian companies registered on Peppol, incoming Peppol invoices are systematically created in the **current user’s company**, instead of the company that actually received the document.

The problem occurs even though the correct journal is identified in `account_edi_proxy_client.user` and used to call `_create_document_from_attachment()`.

### **How to reproduce**

#### **Environment**

* Two Belgian companies: e.g. **Company A** and **Company B**
* Both registered and active on Peppol
* Each company has its own **Peppol purchase journal** (`company.peppol_purchase_journal_id`)
* An accountant with access to both companies

#### **Steps**

1. Trigger Peppol incoming document retrieval (`_peppol_get_new_documents`)

2. Odoo resolves the correct receiving company and journal:

   ```python
   company = edi_user.company_id
   journal = company.peppol_purchase_journal_id
   ```

3. The code uses this journal to import the invoice:

   ```python
   move = journal\
       .with_context(
           default_move_type='in_invoice',
           default_peppol_move_state=content['state'],
           default_peppol_message_uuid=uuid,
       )\
       ._create_document_from_attachment(attachment.id)
   ```

4. **Actual result**:
   The `account.move` is created in **the company of the current user**, *not* in `journal.company_id`.

5. **Expected result**:
   The vendor bill must belong to the company that received the Peppol document (i.e. `journal.company_id`).

This behaviour is reproducible 100% of the time when a user has multiple companies enabled.

---

### **Root Cause**

The selected journal is **never propagated** to the EDI XML decoder.

#### 1. The call in the Peppol module *looks* correct:

```python
journal.with_context(...)._create_document_from_attachment(...)
```

…but `_create_document_from_attachment()` in `account.journal` does *not* use `self` to determine the journal:

```python
invoices = self.env['account.move']
# `self` (journal) is not used at all during decoding
decoders = self.env['account.move']._get_create_document_from_attachment_decoders()
```

So the journal passed to `.with_context()` is effectively **ignored** inside the decoder chain.

#### 2. The XML decoder in `account.edi.format` explicitly uses the *environment company*:

```python
res = edi_format.with_company(self.env.company)._create_invoice_from_xml_tree(...)
```

Thus:

* The company used during invoice creation is **self.env.company**
* That is the **current user’s company**
* Not the Peppol recipient’s company
* Not the journal’s company
* Not the company associated with the Peppol identifier

#### 3. `_create_invoice_from_xml_tree()` supports a journal, but it is never provided

```python
if not journal:
    journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Since `default_journal_id` is **never set**, the fallback is always used.

---

### **Why the fix requires passing `default_journal_id` explicitly**

Even if it **feels redundant**, it is necessary.

* We *are* calling the decoder through `journal.with_context(...)`
* But `_create_document_from_attachment()` does **not** use `self`
* The decoder receives **no reference to the journal**
* And is executed in a context where `self.env.company` = current user’s company

Because Odoo intentionally allows calling `_create_document_from_attachment()` on an **empty journal recordset**, the decoder cannot deduce the journal from `self.id`.

Therefore, the only reliable way to pass the journal down the stack is through the context key `default_journal_id`.

---

### **Proposed Fix**

Add `default_journal_id=journal.id` in the context at the point where the journal is still known:

```diff
--- a/addons/account_peppol/models/account_edi_proxy_user.py
+++ b/addons/account_peppol/models/account_edi_proxy_user.py
@@
 move = journal\
     .with_context(
         default_move_type='in_invoice',
         default_peppol_move_state=content['state'],
         default_peppol_message_uuid=uuid,
+        default_journal_id=journal.id,  # ensure correct company is used
     )\
     ._create_document_from_attachment(attachment.id)
```

This allows the EDI decoder to resolve:

```python
journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Which in turn ensures:

* the invoice is created in `journal.company_id`
* the correct taxes, accounts, fiscal settings, and partner mapping are applied
* multi-company Peppol setups behave as designed

---

### **Impact**

Without this fix:

* All incoming Peppol invoices are created in the wrong company in multi-company environments.
* This leads to:

  * wrong journal assignment
  * wrong fiscal configuration
  * partner mismatches
  * tax errors
  * reconciliation issues

With this fix:

* Each Peppol invoice is correctly routed to the receiving company’s journal
* Behaviour is stable and consistent with Odoo’s EDI design

---

### ✔️ This is a minimal, safe and backward-compatible fix

* It changes only the Peppol integration behavior
* It does not modify EDI core internals
* It uses an existing mechanism (`default_journal_id`) already expected by Odoo
* It matches the intended API contract
* It prevents silent cross-company data corruption

Forward-Port-Of: odoo/odoo#237904

**Steps to reproduce:**
- Go to the restaurant
- Select a table, click on a combo and order it
- Add quantity to the ordered combo and add a note to it
- Select the desired combo options in the popup
- The combos' children lines' qty are not updated and are either too much or 1

**Why the fix:**
When we add a note to an orderline that has qty that has not been sent to the kitchen, we split the line in 2 lines, one with everything that has been sent to the kitchen and one with everything that has not been sent and the note we just added.

This implementation didn't account for the combos, so the combo_line_ids' qty were never updated and stayed as is in the original line, and were set as 1 in the new line.

We now update the children lines' qty at the same time as the parent lines.

This behavior will need to change with the changes made in version  18.3, as this version introduces the possibility of having the same child line multiple times in the same combo, like 2 of the same burger in a single combo.
Another problem is there is currently a bug in 18.3 preventing us from correctly changing the qty of a combo's children by changing the parent's qty if the same item is ordered twice (the qty will still be set to the parent's qty instead of being multiplied). So this will need to be changed once this reaches 18.3

opw-5164102

**Steps to reproduce**

1.Install Accounting, Contacts, and l10n_cz.
2.Create an invoice with a future `invoice date` and confirm it. 
3.Go to Contacts → open the company (res.partner). 
4.Modify any address field (street, zip, etc.) and save. 
5.Return to the invoice → in the chatter, the `date` field has change unexpectedly

> Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction.

**Issue**
- The confirmed invoice `date` changes when updating the company partner’s address.

**Cause**

https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24


- When creating an invoice, the `date` field is correctly set based on the 
`taxable_supply_date` while the invoice is in the draft state. After 
confirming (posting) the invoice, it moves to the `posted` state.

- However, when updating the partner address, the `_compute_date` method 
is triggered again, which calls `super()` and recomputes the `date` field 
using the standard logic. Since the invoice is already in the `posted` 
state, the CZ-specific condition is not satisfied, and the `date` gets 
updated incorrectly.

 **Solution**

- Update `_compute_date` to only call super() for invoices in draft state.
- This prevents unwanted recomputation of the `date` on post invoices.

opw - 5086961

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

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

---
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:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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