Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Forward-Port-Of: odoo/odoo#276563
Forward-Port-Of: odoo/odoo#270067

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#276690
Forward-Port-Of: odoo/odoo#272411

[FIX] fleet: fix vendor bill vehicle association bug

Bug reprod: Go to 19.2 or above

    1 - Go to vendor bills.
    2 - Create an invoice line add vehicle.
    3 - Click to vehicle via the link
    4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...)

Bug cause:

    1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function.
    2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view.
    3 - self.env.context is passed directly as a context
    4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry"
    5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case.
    6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell.
    7 - That's why the context of account_id is passed to the vehicle page as well.

Bug solution:

    1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones.

task - 6385611

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

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

Forward-Port-Of: odoo/odoo#275933

**Steps to reproduce:**
- Create a fiscal position T1, with detect automatically
- Create another one T2, without the detect automatically
- When looking at the fiscal positions list, make sure T1 is on top, followed by T2
- Go to the PoS settings, check flexible taxes
- Put T2 as default and in allowed, don't put T1 in allowed
- Go to the PoS, chose a customer
- The fiscal position is T1 even though it's not allowed

**Why the fix:**

Currently, the fiscal position is chosen like this in order:
- A FP specified on the customer's profile
- A FP detected with the detect automatically setting
- The default FP from the PoS settings

When we have a tie, it's the first one in the fiscal positions list that is chosen.

Before this commit, we did not check that the fiscal position was allowed to be used in the PoS, so we just fetched whatever fiscal position fit the best for a given customer and didn't check if we could actually use it.

We now make sure that the fiscal position we try to use is allowed in the current PoS, and if it's not we fall back to the default one.

opw-6032031

Forward-Port-Of: odoo/odoo#276151
Forward-Port-Of: odoo/odoo#271343

Steps to reproduce:
===================
1. Drop an "Events" block on a website page.
2. In edit mode, try selecting the inner text by clicking multiple times.

=> Uncaught client error: TypeError: Cannot read properties of
   undefined (reading 'nodeType').

Root cause:
===========
When a mouse selection crosses an uncrossable element, the selection restriction plugin moves the focus to the deepest position of the element sibling adjacent to the uncrossable one.

When the first selected node is itself an uncrossable element (event cards are `div` elements) that has no previous/next element sibling, `node.previousElementSibling` is null and `tempFocusNode` was never assigned by a previous iteration, so it is undefined. `nodeSize` then reads `nodeType` on undefined and throws.

The plugin only exists from saas-19.3, which is why the issue is not reproducible on earlier versions.

Fix:
====
When there is no sibling to place the focus on, fall back to the boundary just outside the uncrossable node itself (`leftPos` when selecting left to right, `rightPos` when selecting right to left) instead of calling `nodeSize`/`getDeepestPosition` with undefined.

opw-6362955


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

Forward-Port-Of: odoo/odoo#274739

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#276307
Forward-Port-Of: odoo/odoo#271829

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

Ticket [link](https://www.odoo.com/odoo/project.task/6260427)
opw-6260427

Forward-Port-Of: odoo/odoo#275401
Forward-Port-Of: odoo/odoo#267781

### Steps to reproduce:

- Open the Todo app
- In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>`
- Double-click the empty unbreakable node
- Open the color picker and hover over a color
- Toolbar and color picker get closed

### Root cause:

- Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()` finds no `<br>` and no visible text, returns false, and closes the toolbar — which reverts the preview, reopens the toolbar, and causes a flicker loop.

### Solution:

- Instead of calling `fillEmpty()` (which inserts a ZWS placeholder) on empty blocks containing `<br>` preserve the `<br>` element by appending it directly inside the `<font>` tag which keeps toolbar open.

task-6312933

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

Forward-Port-Of: odoo/odoo#276776
Forward-Port-Of: odoo/odoo#271507

[FIX] fleet: fix vendor bill vehicle association bug

Bug reprod: Go to 19.2 or above

    1 - Go to vendor bills.
    2 - Create an invoice line add vehicle.
    3 - Click to vehicle via the link
    4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...)

Bug cause:

    1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function.
    2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view.
    3 - self.env.context is passed directly as a context
    4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry"
    5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case.
    6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell.
    7 - That's why the context of account_id is passed to the vehicle page as well.

Bug solution:

    1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones.

task - 6385611

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

**Description of the problem**
The age verification popup snippet (`s_age_verification_popup`) does not work properly when dropped into the `#product_details` element of a product page. In particular, the popup is rendered below the blurred background and cannot be interacted with (it should be rendered above the blur instead).

**How to reproduce**
1. Open a product page.
2. Drop `s_age_verification_popup` into the product details.
3. The popup is rendered below the blurred background.

**Why the problem happens**
The `s_age_verification_popup` snippet applies the blur effect to the `#wrapwrap` element. The popup is expected to be rendered above the blur thanks to its `z-index`.
However, `z-index` only applies within the same stacking context. A child element cannot be rendered above elements outside its parent's stacking context, regardless of how high its own `z-index` is. Since `#product_details` has a defined `z-index`, it creates a stacking context. As a result, the popup, which is a child of `#product_details`, is rendered below the blur element.

**Fix**
This commit adds an SCSS rule to `#product_details` so that it no longer creates a stacking context when it contains an open age verification popup. To prevent the stacking context from being created, `z-index` is set to `auto` and `position` to `relative`.

task-6358990

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

Forward-Port-Of: odoo/odoo#275933

\* : html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

Forward-Port-Of: odoo/odoo#275693
Forward-Port-Of: odoo/odoo#199193

Step to reproduce:
- install l10n_sa_edi_pos in fresh db, make sure to have a saudi arabia company
- go to sales journal -> zatca page (journal should not be onboarded_
- open pos and make a sale -> print receipt

Observaton:
- in receipt notice a label "This is not a legal document"
- such labels should only appear when we are on phase 2 i.e. we onboard journal

Cause:
- after the commit [1] we removed dependency b/w account_edi and l10n_sa
- Also, visibilty of label dependends on
 - `l10n_sa_not_legal` , `code_sa` and  `l10n_gcc_is_settlement`
- here we never checked, which phase we are in [1] https://github.com/odoo/odoo/commit/1c463a4d5b513fcf17a9ea0ea26bf50f68102193

fix:
- we keep track, if config's journal is onboarderd or not (by presense of csid)
and only then we decided to print label (if applicable)

Before:

<img width="1829" height="1040" alt="image" src="https://github.com/user-attachments/assets/581923c0-513c-45dc-8b77-6ab171dc0522" />


After:
<img width="1827" height="1037" alt="image" src="https://github.com/user-attachments/assets/dfdfde21-c17d-4468-9629-9ac1fd6d691c" />


opw-6317777

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

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#276307
Forward-Port-Of: odoo/odoo#271829

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276308

\* : html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

Forward-Port-Of: odoo/odoo#275334
Forward-Port-Of: odoo/odoo#199193

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

Forward-Port-Of: odoo/odoo#275933

When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs.

The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal.

Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64().

Description of the issue/feature this PR addresses:

Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually.

Desired behavior after PR is merged: Subscriptions get renewed successfully.


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

Forward-Port-Of: odoo/odoo#276085
Forward-Port-Of: odoo/odoo#275217

### Overview

The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies.

### Changes

Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sms batch is multi company.

After this commit, the _process_queue method now follows the same pattern as the send method, grouping by sms_api / company within the batch, and eliminating the need to check for singleton, as all calls to _send will now have the sms_api context passed in.

### Steps to Reproduce on fresh 19.0 db:
1. Make sure sms / sms_twilio are installed.
2. Create two companies with their own SMS config.
3. Create two sms records, one with each company.
4. Ensure the state of the sms's is 'outgoing'.
5. Execute the SMS Queue Manager Cron. Observe the traceback: ValueError: Expected singleton...

opw-6371272

Forward-Port-Of: odoo/odoo#276426

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#276430
Forward-Port-Of: odoo/odoo#273129

Steps to reproduce:
- Go to Website
- Upload an image in the company logo (navbar)
- Open the website editor and click on the logo
- Open the image info panel

Current behavior:

When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't.

Reason:

When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment.

The website logo is served through a dynamic link
(`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with.

As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes.

Fix:

When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo.

opw-6260496

Forward-Port-Of: odoo/odoo#273542

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#272411

### Steps to reproduce:

- In the settings enable Multi-Steps route
- Unarchive the MTO route and set its production rule in MTSO
- Create 3 products: P1, P2 and COMP all using the MTO route
- Create 2 BOM's, one for P1 and one for P2: 1 X COMP
- Put 2 units of COMP in stock and add an empty bom (to trigger a child MO creation in case the MTSO route is triggered)
- Create and confirm a sale order for: 1 x P1 and 1 X P2
#### > An MO was generated for both product but P2 also generated a child MO for 1 unit of COMP instead of using the available unit

Cause of the issue:

The issue happens in the `_prepare_procurement_qty` which incorrectly assess that 1 unit of COMP will be required. The issue has been introduced by commit https://github.com/odoo/odoo/commit/e30fb722c00805e7226d2ee9e3e587b3c2204840 which introduced a dictionary to keep track of units of  products that will be used by the confirmation process of other concurrent mtso moves: https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1683-L1689 https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1712-L1715 https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/stock/models/stock_move.py#L1810-L1814 
While by design this propagates the information used by other mtso moves in a common `_action_confirm` stack, the issue that we encounter is that this quantity is only relevant to be substracted to the free_qty when the unit is not yet reserved and hence already accounted negatively in `free_qty`. However, in the present case, confirming the receipt of P1 and P2 will confirm both moves simultaneously, triggering a common `_run_manufacture` to generate both an MO for P1 and for P2. At this point the dictionary `consumed_from_stock_dict` is shared in both MO's confirmation but since the MO's are confirmed sequentially rather than in batch:
https://github.com/odoo/odoo/blob/71f0715bd5e29e976a1e8bfa7c4fa6e04735ebd7/addons/mrp/models/stock_rule.py#L122-L125
The confirmation of the MO of P1 will update the `consumed_from_stock_dict` for 1 unit of COMP and will also reserve 1 unit of COMP before the MO of P2 is confirmed (and calls the `_prepare_procurement_qty`) to determine how many units of COMP are till available. This leads to the incorrect conclusion that 1 - 1 = 0 units are still available to fulfill the demand of P2.

opw-6370298

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

Forward-Port-Of: odoo/odoo#275539

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#276307
Forward-Port-Of: odoo/odoo#271829

Steps to reproduce:
-------------------
- Install `mrp` and `sale_management` modules
- Enable Units of Measure from settings
- Create a storable product configured as a Kit:
  - Set UoM to Units
  - Add component and it's UoM in Kg in Product form.
- Create and confirm a Sales Order with the kit product
- Validate the generated delivery order
- Print the delivery slip

Issue:
------
The delivery slip correctly displays component quantities in Kg,
but also shows an additional converted quantity in Units (e.g., 1000 Units),
which is incorrect and misleading.

Cause:
------
During sale order confirmation, the following flow is executed:
`action_confirm → _action_confirm → _action_launch_stock_rule → _prepare_procurement_values`

In `_prepare_procurement_values`, the `packaging_uom_id` is set from the
sale order line UoM (Units) and propagated to the generated stock move:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/sale_stock/models/sale_order_line.py#L296

When the delivery (picking) is created, kit components generate stock moves where:
- `product_uom` is defined in the component’s UoM (e.g., Kg)
- `packaging_uom_id` remains in Units (inherited from the sale order line)

While generating the delivery slip, `_get_aggregated_product_quantities`
computes `packaging_quantity` using `packaging_uom_id`:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/models/stock_move_line.py#L888

In Mrp this calls the template:
`stock_report_delivery_aggregated_move_lines`
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/mrp/report/report_deliveryslip.xml#L60


In this template, a condition renders packaging quantities when
`packaging_uom_id` differs from `product_uom`. As a result, quantities are
converted from the component UoM (Kg) into the packaging UoM (Units).

https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/report/report_deliveryslip.xml#L261

For kit components, this conversion is not meaningful and leads to incorrect
values (e.g., Kg → Units resulting in 1000 Units), causing misleading output
in the delivery slip.

Fix:
----

Add a `_compute_packaging_uom_id` override in `sale_mrp` and
`purchase_mrp` that resets `packaging_uom_id` back to
the component's own `product_uom` whenever the move originates from a
phantom BoM line, without touching `sale_line_id`/`purchase_line_id`
themselves.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/5d8b2154-d794-4ce4-90a6-1a0aeaca8604" />
  </div>

  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/79d708de-19e3-452d-9033-322a297c38e9" />
  </div>
</details>

---

opw-6136928

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

Forward-Port-Of: odoo/odoo#262705

**Issue 1:**

Steps to reproduce:
- Install the `l10n_ar` module.
- Go to Customers and create a new customer with the country set to Argentina.
- Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`.

**Error:**
`ValueError: invalid literal for int() with base 10: '1234567890a'`

**Issue 2:**
- Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`.
- Set `Identification Number` to `1234567890a`.

**Observation:**
All non-digit characters are stripped, and the identification number is 
silently changed to `1234567890`.

**Expected behaviour:**
Any Identification Type other than CUIT (80), CUIL (86), and DNI (96)
should be kept unchanged without stripping alphabetic characters.

**Root Cause:**
At [1], `_get_id_number_sanitize` sanitizes identification numbers
based on the selected Identification Type.

- For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes 
  separators (e.g., spaces and dashes). If the identification number
  contains alphabetic characters, they are preserved and called `int()` 
  on the resulting value, raising a `ValueError`.
- For all other identification types, valid alphanumeric values are
  unintentionally modified by stripping non-digit characters.

**Fix:**
This commit validates identification numbers before sanitization for
`CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric
identification numbers are converted. For all other identification
types, it preserves alphanumeric characters by removing only
non-alphanumeric separators.

[1]:
https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136

Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729

opw-6333998

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#269100

For a logged-in user, some form fields are automatically prefilled from
their profile, such as a "Phone" field with their phone number.

**Issue:**
The prefill configuration is always preserved when we change options of
a field. While this is correct when updating few options, but it also
happens after the field is repurposed, causing it to inherit a prefill
value intended for a different field.

**Steps to reproduce:**
- Edit the /contactus page's form.
- Change the "Name" field's type to a "URL" or "CC" field.
- Save the changes.
- The "URL/CC" field is prefilled with the user's name.

A field is considered repurposed when:
- its type is changed (e.g. from "Phone" to "URL");
- a custom field is converted into an existing field.

**Fix:**
This commit preserves the prefill only when the field keeps the same
name and type. Otherwise, it clears the stale prefill so repurposed
fields no longer inherit incorrect values.

task-[5976747](https://www.odoo.com/odoo/project/974/tasks/5976747)

Forward-Port-Of: odoo/odoo#275812

Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and opened the marker popover.

This was racy. Closing `pinListPopover` triggers a re-render of the view, during which all markers are removed and re-added. If that re-render happened after the popover was opened, the marker element the popover was anchored to no longer existed, and the popover closed itself through `Popover.onTargetMutate()` (which closes the popover when its target element leaves the DOM). Depending on timing, the popover would sometimes be destroyed right after being opened, making the test flaky and leaving no popover open in the browser.

To fix this, `centerAndOpenPin` is split in two parts:
* it now only closes `pinListPopover` and raises a `shouldOpenMarkerPopover` flag;
* on the next `onPatched`, once the markers have been re-rendered, the new `centerAndOpenPinOnPatched` method centers the map on the marker and opens the popover.

Opening the popover after the re-render guarantees the marker element is present, removing the race condition.

runbot-error-944199

Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete.

### Steps to reproduce

1. Create many messages, ensuring some are hidden from a specific user via access rules.
2. Open the message list view as that user.
3. Pagination incorrectly shows a total matching the current page (e.g., "1-68 / 68") instead of the full count (e.g., "1-80 / 5000+").
4. Because the system believes all records are displayed, the "Next" page button is disabled, leaving the user stuck on the current page despite more records existing in the database.

### Cause

The `mail.message` model filters records in Python after fetching them from the database to enforce complex access rules.

1. The system queries the database for a batch of records up to the view's limit.
2. The `_search` method removes inaccessible records from this batch.
3. The web client receives fewer records than the requested limit.
4. Interpreting this as the end of the dataset, the web client skips the count query and displays the current batch size as the total.

### Fix

Add `'force_search_count': 1` to the action context. This forces the web client to execute a separate count query to determine the total number of records, regardless of the batch size returned.

opw-5425361

When searching on the Website site, using the main search on the navbar, it opens a list view with the results (`website.list_hybrid`) which raises the warning on the logs (2 times):
"Unknown directives or unused attributes: {'t-key'} in website.list_hybrid"

![Task 79454 - Issue 434 - Image of Warnings](https://github.com/user-attachments/assets/f5a3100b-c617-4c38-a8b5-f42427a4317c)

This happens after the attribute `t-key` was added to the template [\[1\]] because the template is only used in QWeb. The validation for them doesn't include the `t-key` [\[2\]] as one of the "iter_directives" nor has a `_compile_directive_*` method to check and remove it from the validation as it's done with the `t-as` and `t-foreach`.

This also causes the raise of the warnings on tours that use the tour method `searchProduct` (of the module `website_sale`) because it uses the first input with the name of search and happens to be the search on the navbar.

![Task 79454 - Issue 434 - Search Input](https://github.com/user-attachments/assets/923f5d63-5cfb-4c0b-a563-0eabc04882bb)

[\[1\]]: https://github.com/odoo/odoo/commit/7b1d82aa
[\[2\]]: https://github.com/odoo/odoo/blob/f52cfb09/odoo/addons/base/models/ir_qweb.py#L1400

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

Forward-Port-Of: odoo/odoo#179017

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#272161

For a logged-in user, some form fields are automatically prefilled from
their profile, such as a "Phone" field with their phone number.

**Issue:**
The prefill configuration is always preserved when we change options of
a field. While this is correct when updating few options, but it also
happens after the field is repurposed, causing it to inherit a prefill
value intended for a different field.

**Steps to reproduce:**
- Edit the /contactus page's form.
- Change the "Name" field's type to a "URL" or "CC" field.
- Save the changes.
- The "URL/CC" field is prefilled with the user's name.

A field is considered repurposed when:
- its type is changed (e.g. from "Phone" to "URL");
- a custom field is converted into an existing field.

**Fix:**
This commit preserves the prefill only when the field keeps the same
name and type. Otherwise, it clears the stale prefill so repurposed
fields no longer inherit incorrect values.

task-[5976747](https://www.odoo.com/odoo/project/974/tasks/5976747)

Forward-Port-Of: odoo/odoo#275812

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`.

Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become `["P00001", "P00002"]`.

That still leaves a bad case: blank or whitespace-only content still produces empty refs. For example, `","` becomes `['', '']`, and since https://github.com/odoo/odoo/pull/225294 on 18.4+ during foward port it's gotten even worse: " commission" becomes `['', 'commission']`

This problematic because `invoice_origin` does not always contain real PO refs. Since odoo/odoo#207037, XML imports can also fill it with concatenated line descriptions which contains arbitrary text. We recently hit this on odoo.com with a Peppol bill where this led to parsed refs including `''`.

Once `['']` is passed to `_match_purchase_orders()`, POs with an empty `partner_ref` can enter the candidate set. From there, the normal amount or line matching can link the bill to a wrong PO (which will always happen with the number of POs and PO lines we have on prod)