Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

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

In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location

Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})

Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119

opw-5268989

Forward-Port-Of: odoo/enterprise#102902

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

Forward-Port-Of: odoo/odoo#242692

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Forward-Port-Of: odoo/odoo#245865

### Issue:
Stripe payment is failing in some special currencies (e.g. ISK, UGX).

### Steps to reproduce:
1- Configure Stripe
2- Enable ISK currency
3- Create a SO with ISK currency and generate a payment.
4- Pay using Stripe.

The payment will fail due to the amount mismatch.

### Cause:
Commit https://github.com/odoo/odoo/commit/9493475273a40320228b92940be15ad8cb0643cb added support for special currency but did not adapt amount validation method in fw.

In stripe payload, we are using `const.CURRENCY_DECIMALS` as `arbitrary_decimal_number` to convert the amount to minor currency unit:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L161-L166

However, we are not using the same constant in conversion back to major currency unit in `compare_notification_data`:
https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L393-L395

opw-5871420

Forward-Port-Of: odoo/odoo#245911
Forward-Port-Of: odoo/odoo#245689

*= co, ec, kr, us, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

Forward-Port-Of: odoo/enterprise#105838
Forward-Port-Of: odoo/enterprise#105262

Steps to reproduce the bug

- Create a storable product P1:
  - Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
  - Manage Users
    - Mitchell Admin
      - Sales: User: own documents only
- Go to the Serial Numbers list view:
  - Try to open SN1

**Problem:**
An access error is triggered:

```
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)

Blame the following rules:
- Personal Order Lines
```

When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.

Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.

There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.

**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.

opw-5400731

Forward-Port-Of: odoo/odoo#246009
Forward-Port-Of: odoo/odoo#244570

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105102
Forward-Port-Of: odoo/enterprise#102557

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
Backport of https://github.com/odoo/enterprise/pull/104885

Forward-Port-Of: odoo/enterprise#105022