This PR fixes the bug of not making the source location persistent when changing it from the form view.

To reproduce the bug:
1- Create a product tracked by lot.
2- Create 3 different lot locations with each having a quantity of 100. 
3- Create an out delivery of 140 and notice 100 are assigned from the first lot and 40 are assigned from the second lot.
4- Set the scanning source location to be mandatory in Barcode for deliveries.
5- Go to Barcode app, navigate to the delivery, you find it mandatory to scan a source location.
6- Scan the source location for the first lot location, choose the product and click on the edit pen icon.
7- Choose another lot location as your source location, let it be the third lot location and confirm.
8- Choose to assign the qty by clicking on the +100 button.
= See that the new chosen source location is not persistent.

The fix:
After this PR, if you follow the steps up to step 7 and after you confirm your new source location, the Barcode makes the lines inactive again and asks you to scan the source location (since it's mandatory) and it also shows the new source location on the line.

Another fix this commit addresses is that when you scan a source location, only the lines with this location are active to choose/edit not all the lines.

Task-4809491

Forward-Port-Of: odoo/enterprise#97777

## Context
There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers the features and for developers to test the UI 💡

Though useful, this feature can be confusing. Users may not realize they aren't in Production Mode, and developers may forget to switch back to Demo Mode when testing the UI.

535a7aef3e410d997baa093cc111527814c29253 improved the situation by displaying "Demo Mode" in the Softphone header when Demo Mode is enabled. It was intended to include a tooltip explaining how to configure Production Mode when hovering over it. However, although the tooltip text is present in the code, it was not correctly mapped to the "demo indicator"  ¯\\\_(ツ)\_/¯

## In this PR
After this commit,
- the tooltip text is correctly provided to the "demo indicator", enabling it to be displayed on hover;
- the tooltip text is slightly reworded in the hope of making it clearer.

[Task-5804537](https://www.odoo.com/odoo/project/5778/tasks/5804537)
Fix https://github.com/odoo/enterprise/pull/95742

Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.

Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
    - Line (A) -> [] (multi checkbox type)
    - Line (B) -> [attr_1, attr_2] 
    - The possible combinations are {(attr_1), (attr_2)}.
  
  After generating the second combination the following 2 procedures happen.
    - The value_index_per_line[1] will be resetted to -1,
    - The line_index will decrement from 1 to 0. 


Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.

Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.


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

Forward-Port-Of: odoo/odoo#241557

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.

Forward-Port-Of: odoo/enterprise#104996
Forward-Port-Of: odoo/enterprise#104619

**Steps to reproduce:**
- Create a storable product "P1"
  - Product category: AVCO

- Create a purchase order with 100 units of P1 at $10
- Confirm the PO and validate the receipt
- Go to Inventory -> Reporting -> Stock

- P1 unit cost is $10 and total value is $1000

- Click on $1000
  - Select the first stock move
  - Action -> Adjust valuation
    - New value: $2000 -> Save

- Go back to Inventory -> Reporting -> Stock

**Problem:**
- The unit cost becomes $2,000 and the total value $200,000

When a valuation adjustment is made on an AVCO product, a `product.value`
record is created with the new total valuation value.

However, `product.value.value` can represent two different things:
- for a standard price update, `value` contains the new unit cost
- for a stock move valuation, `value` contains the total value of the move

When `run_avco` processes a `product.value` coming from a move valuation,
it incorrectly treats the value as a unit price and multiplies it by
the quantity

opw-5460829

Forward-Port-Of: odoo/odoo#244957

### Issue:
Due to this issue, by clicking twice on `Reward` button on SO, reward line unit price will be reset to zero.

#### To reproduce:
1- Create a `Buy X Get Y` program:
   rule: minimum quantity: 3, product: `Large Desk Wood`
   reward: 1 `Large Desk Wood` for free
2- Create a SO, and add a line with 3 `Large Desk Wood`
3- Click on `Reward` button. A new line should be automatically
   created. The unit price should be the product sale price and
   line `Amount` should be 0.
4- Re-click on reward. The reward line price unit is set to zero.

Expected: The reward line price unit should remain as product sale price with a discount of 100 and line.amount of 0.

### Cause and Fix:
In `_reset_loyalty`, price_unit is set to zero.
The method `compute_amount` depends on `price_unit`, which means setting `price_unit` will make amount to be recomputed: https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L843-L844 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L848 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/account/models/account_tax.py#L1613

Which leads to `_compute_price_unit`. In this compute, the unit price will not be recomputed if `technical_price_unit` and `price_unit` differ.
https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L606-L611 https://github.com/odoo/odoo/blob/4fa9f9b849016f312efcb73f9a76b223e429aec0/addons/sale/models/sale_order_line.py#L588-L595

So IMO if we want to recompute `price_unit`, we need to also reset `technical_price_unit` in `_reset_loyalty`.

opw-5467623

Forward-Port-Of: odoo/odoo#244290

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104845
Forward-Port-Of: odoo/enterprise#99820

### [FIX] mail: properly handle col overflow in bootstrap row
Problem:
The grid conversion logic only finalized a row when iterating through the
last column in the input list. If a row reached exactly 12 grid spans
while more columns remained (e.g., a `col-12` in the middle), the logic
did not start a new row. As a result, remaining columns overflowed the
current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of
any size, it would crash because the algorithm did not reset the index to the
start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

### [FIX] mail: ensure -md variant of col and offsets are prioritized
Prior to this commit, if an element had a mix of `col-x` and `col-md-y` classes,
the regexes used in `convert_inline` would not guarantee that they would be used
consistently.

How to reproduce:
- create a new mailing and add the "three columns" snippet
- resize from the right the middle column (reduce the size and revert back to
  the original size)

Issue:
- when sending the email, the columns are not aligned horizontally in a desktop
  layout

Solution:
Prioritize usage of `-md` variants to compute the size of a column/offset, when
available (these are the one used by the mass_mailing editor for desktop mode),
and use any otherwise.

opw-5439481

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>
Co-authored-by: Walid Sahli <wasa@odoo.com>

Forward-Port-Of: odoo/odoo#241851

### Issue:
The stripe payments are failing to due setting currency decimals.

#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
   to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through stripe. As you see payments fail.

### Cause:
This is due to rounding the amount before sending to stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165

We are rounding the amount to the minor currency unit.

However, we make a compare between `tx_amount` and the amount paid through stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732

Which are not equal. We should use minor current unit as `precision_digits` to fix this issue.

opw-5496825

Forward-Port-Of: odoo/odoo#245593
Forward-Port-Of: odoo/odoo#245059

While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the  EDI builder. However, this method is only implemented for the ```account.edi.xml.ubl_bis3``` builder and is not available on other EDI formats such as ```oioubl_21```,
```oioubl_201```.

When a partner is configured to use the ```oioubl_21``` eInvoice format,
this resulted in an ```AttributeError``` during record reads, causing menu crawl and
UI access failures (e.g., Accounting → Vendors → Bills/Refunds).

```sql
 Traceback (most recent call last):
   File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 13, in _compute_can_send_as_self_invoice
    if move._is_exportable_as_self_invoice():
   File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 31, in _is_exportable_as_self_invoice
    and edi_builder._can_export_selfbilling()
 AttributeError: 'account.edi.xml.oioubl_21' object has no attribute '_can_export_selfbilling'
```
**Steps to reproduce**
1) Install l10n_dk_nemhandel module
2) Set the eInvoice format to oioubl_21 for the partner
3) Create Bill for that partner
3) Confirm the bill

OPW - 5863081
UPG - 3846482




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

Forward-Port-Of: odoo/odoo#245391