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

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

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:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#244428

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

Forward-Port-Of: odoo/odoo#230500