The PR is the enterprise counterpart of https://github.com/odoo/odoo/pull/250051

Here is the original message:
The commit aims to improve the UX on touch screens, by improving
inputs and buttons design to make them more usable on those touch
oriented devices first by giving more space around certain elements
and making other UI elements more compact to give the user more
information. As a side effect, this task also allowed to improve the
desktop experience regarding suffixes and to unify the look and
feel of text inputs.

A dedicated o_input_box class has been added. Being used at the highest
level on an input/button element or its parent in the UI, it can be used
to add overlay prefix and/or suffix inside of them, using on those UI
elements the 'o_input_box_overlay + prefix/suffix' classnames.

For example:
```
<div class='o_input_box'>
    <i class='fa fa-gear o_input_box_overlay prefix'/>
    <input class='o_input'/>
    <button class='btn btn-link o_input_box_overlay suffix'>Click Me</button>
    <i class='fa fa-arrow o_input_box_overlay suffix'/>
</div>
```

In this example, an input box would be display around the input, with
enough padding before and after the input value, displaying 2 icons
and a button.

Currently, positioning the overlay elements require to call the dedicated
utility function, exported from '/web/static/src/core/input_box.js'.
Padding is then calculated and adapted accordingly to maintain affordance
of the input or button text, and place the dropdown arrow.

An InputBox component has been added as well, implementing easily the right
elements around an input, but it is possible to use the classnames without
the need for this specific component.

If an element with o_input_box is contained inside another o_input_box
parent, the highest element is considered as the input box, and displayed
correctly. This allows a component that already have the class to have a
sibling element serving as an overlay, by adding a parent to both elements
having the o_input_class. It is also useful when some UI is declared from
the arch XML while other overlays are defined from the component side.

This commit also removes the need of a dedicated component for the boolean
toggle field in list views. The edition of any boolean field in
readonly/non selected rows in list views is already well handled in a
scss rule, and it is not necessary to have this dedicated wrapper around
the standard BooleanToggleField component.

task-5355007

## Versions
17.0+

## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.

## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
  - Setup Avatax;
  - Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
  - Go to the shop;
  - Add the product you created to the cart;
  - Enter the cart;
  - Click the "Buy with GPay" button:
    - The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
  - The total amount differs from the amount paid (cf. transaction).

opw-5020793

Forward-Port-Of: odoo/enterprise#109121
Forward-Port-Of: odoo/enterprise#101579

Task Adhoc side: 56583
Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view

The error was this one:

Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)

Forward-Port-Of: odoo/enterprise#100457

Steps to reproduce:
1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse).
2. Generate a payslip for this employee.
3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV).
4. Observe that the employee's name is displayed instead of the account holder's information.

Issue:
Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder.

Solution:
Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner:
- Updated QWeb templates to display bank.partner_id.name for account allocations.
- Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID.
- Ensured a fallback to the employee's legal name remains in place.

opw-5357652

Forward-Port-Of: odoo/enterprise#108785
Forward-Port-Of: odoo/enterprise#106718

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

Forward-Port-Of: odoo/enterprise#109237
Forward-Port-Of: odoo/enterprise#103207

How to reproduce
------
1. Open the Marketing Automation app
2. Create a new campaign
3. Click on Add new activity to create a new activity (in the previously created campagin)
4. Set the Activity Type to email
5. In the Mail Template option, select or create a mailing
6. Open the selected/created mailing (using the Templates smart button)
7. Click on the gear icon and then click Delete (either one or multiple together)

DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570

Current behavior
-----
Odoo Server Error is displayed.

Expected behavior
------
Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign).

Cause
------
When formatting the user error, we used the attribute `name`, to
get the mailing's display name, which does not exist in `mailing.mailing`
model. Therefore, a KeyError is raised.
The `name` attribute was an attribute in a class named `UtmSourceMixin` in
the utm module, of which `mailing.mailing` was inheriting. In saas-19.2,
that class was removed and hence the `name` is no longer available for
`mailing.mailing`.
The commit in which the metioned class was removed is:
https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5
(See utm_source.py)

Solution
------
Change the `name` to `mailing.display_name`.
DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761

task-5999999

Forward-Port-Of: odoo/enterprise#109400

## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.

<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
    - Any Customer
    - Any Recurring Plan
    - Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**

## Cause
The title shown in the preview is defined here:

https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195

The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237

The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.

## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:

https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803

<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />

## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.

opw-5489970

Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767