### Steps to Reproduce:
1. Go to Sales > Products and select a product
2. Upload an image for the product
3. Go to Settings > Technical > Attachments
4. Click on one of the image attachments
5. Observe the Client Error: "Uncaught Promise > Invalid props for
component 'Many2One': 'domain' is not a function"

### Issue:
In `attachment_patch.js`, the domain for the `Many2OneReferenceField` is overridden when an attachment is linked to another attachment. The patch calculates the domain and incorrectly assigns a static Array (using `.toList()`) to `props.domain`. In Odoo 19, the `Many2One` component enforces strict prop validation (caught when Owl's debug mode is enabled during testing), causing a crash because it expects the domain prop to be a function.

### Solution:
We can just wrap the resulting domain Array in an arrow function so that it evaluates dynamically when the `Many2One` component mounts. Also added a unit test to explicitly cover this patched scenario. The test manually applies a local patch to `Many2OneReferenceField.prototype` to accurately replicate the environment and verify the fix.

opw-6563954

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

Forward-Port-Of: odoo/odoo#287951

### Steps to Reproduce:
1. Duplicate an Inventory Location so that you have one that is NOT a sublocation of any other location
2. Go to the Barcode module and click "Add Product"
3. Choose a product
4. For the location, select the new location
5. Click Confirm and observe the Traceback

### Issue:
In the Barcode module, selecting a location that falls outside the stock locations hierarchy causes a traceback. The initial frontend cache is designed to only preload sublocations of the primary stock location. When a user selects an un-cached location, the subsequent quant data fetch assumes the location is already cached and omits it from the payload, which causes an `UncaughtPromiseError` when the UI attempts to rebuild.

### Solution:
We can update `get_stock_barcode_data_records` in `stock.quant` to explicitly include the `stock.location` data in the returned payload. This mirrors how products and lots are handled, ensuring the frontend always receives the necessary location records even if they were excluded from the initial startup cache.

opw-6469721

Forward-Port-Of: odoo/enterprise#128147

Since [1], the registry is loaded without a request context, so a module installation now goes through the fallback of `get_current_website` that reads the url stored on the current thread. That value is a full url, not the `domain:port` the method expects, so IDNA-encoding it splits it on the dots of the path rather than on those of a host name and raises `UnicodeError` as soon as one of the resulting parts reaches 64 characters.

The thread url is now reduced to its `domain:port` part.

Steps to reproduce:
- Start the server locally on a database with demo data, served on `http://localhost:8069`, with only `Website` installed
- Create a new website
- In the configurator, choose `I want an online store`
- Go through each step
- After the last step, a traceback appears while loading the accounting demo data: the configurator should apply without error

[1]: https://github.com/odoo/odoo/commit/1ae80f9fb18c9c9e67fe0367b94f0d882c711570


Also reported here: https://github.com/odoo/odoo/issues/286432

Forward-Port-Of: odoo/odoo#288931

Steps to reproduce:
- Create a DB and Install `Accounting` without demo data
- In Companies > Create New Company with `US` Localization
- Switch to US Company > Add `Avatax` Credentials
- Create a Product with `Avatax Category`
- Create a Invoice > In Other Info `Fiscal Position` - `Automatic Tax Mapping (AvaTax)` > `Compute Taxes`
- In Taxes check newly created tax does not have a account ID

Issue:
AvaTax fiscal position created from chart templates have empty `avatax_invoice_account_id` and `avatax_refund_account_id` fields on a fresh database without demo data.

Problem:
Both fields use [defaults] based on `company.account_sale_tax_id`. During initial CoA loading, `_load_data()` creates the AvaTax fiscal position before `_post_load_data()` sets `company.account_sale_tax_id`. The defaults therefore resolve to an empty recordset and no tax account is assigned. This issue does not occur in databases with demo data because the demo company is already loaded, so `company.account_sale_tax_id` is already set when the AvaTax fiscal position is created.

Solution:
Set the invoice and refund accounts explicitly in the AvaTax fiscal position template to ensure they are correctly assigned during CoA loading.

[defaults]: https://github.com/odoo/enterprise/blob/de17c107651394025e9a3d5cbed8d81bcfc2e76d/account_avatax/models/account_fiscal_position.py#L9-L13

opw-6347128

Forward-Port-Of: odoo/enterprise#132005
Forward-Port-Of: odoo/enterprise#126604

Currently, an error occurs when a user clicks on a cell in the aged partner balance report.

**Steps to Reproduce:**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Reporting` > `Partner Reports` > `Aged Receivable`.
 - Click on the `date filter`, select `Open On`, and set `any date`.
 - Click on any `amount` in the `Total Aged Receivable line`.

`TypeError: the JSON object must be str, bytes or bytearray, not dict`

After the [recent commit] that adds the context to the action, when preparing the action to open 
the journal items corresponding to the selected cell in the aged partner balance report, the 
context is added to the action [1]. When an "Open On" date is set, the code attempts to 
convert the context using json.loads() before adding the search_default_open_on key to 
it [2]. but, the context is already a dictionary, which raises the error [3].

This commit ensures that, since the action context is already a dictionary, the search_default_open_on 
key and its value are added directly to the context.

[recent commit]: https://github.com/odoo/enterprise/commit/9678a1b987a5aa87922b72d972dd7f73a689afee

[1]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L357-L359

[2]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L362

[3]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L361

sentry-7685491449

This commit aims to adapt the tests for this bugfix.

How to reproduce:
- Create livechat channel with 0 members.
- In Rules, add an agent to the channel.
- In website configuration, set the created livechat channel as the default live chat channel.
- Go to website, click bottom right bubble to start livechat.
- Resize the Window on your screen so that the chat window obscures the top right of the page (where you get notifications)
- Press 'Ask a Human'

Current behavior:
- 'Ask a Human' is available (despite having 0 agants in the channel -> will never reach a human)
- Notification is obscured by the chat window (when it overlaps with the top right)

Expected:
- Remove 'Ask a Human' button, when there are no human (agents) in the livechat channel
- Change the notification to a chat message.

enterprise PR: https://github.com/odoo/enterprise/pull/125673
task: 6148037

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

Steps to reproduce:
===================
1. Publish a combo product whose choices each offer more than one item, so the combo configurator is shown.
2. On the shop, open the product and click "Add to Cart".
3. Select an item for one combo choice only. The dialog's "Add to cart" button stays disabled.
4. Remove the `disabled` attribute from that button with the browser developer tools and click it.

=> The combo is added to the cart with one of its choices unanswered, and the order can be paid in that state.

Root cause:
===========
The incomplete selection is only prevented on the client side, by disabling the button until every choice has been answered. Server side, `/website_sale/combo_configurator/update_cart` only rejects a completely empty selection, never that the selected items cover every choice.

Fix:
====
Reject the request unless the selected combo items cover exactly the combo choices of the product. Comparing the set of choices rather than counting the items also rejects a selection answering the same choice twice while leaving another one unanswered.

opw-6478837

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

Forward-Port-Of: odoo/odoo#286989
Forward-Port-Of: odoo/odoo#283465

Steps to reproduce:
===================
1. Create a storable product with two variants and untick "Continue selling when out-of-stock".
2. Leave the first variant at 0 in stock, put some stock on the second one.
3. try the "Add to Cart" option of the shop page.

=> The product has no add to cart button, as if it were sold out, while its second variant can be bought. Reordering the variants so that the one in stock comes first brings the button back.

Root cause:
===========
`product.template._is_sold_out()` delegates to `product_variant_id`, which is `product_variant_ids[:1]`, so a whole template is declared sold out on the sole basis of its first variant. `_website_show_quick_add()` then hides the button for the template, whatever the stock of the other variants.

The helper has looked at that single variant since it was written:

- [1] added it to hide the button of sold out products.

Fix:
====
Consider the template sold out only when all of its variants are. The check stops at the first variant in stock, so a product that can be bought still costs a single stock lookup.

[1]: https://github.com/odoo/odoo/commit/4ae197cc770cec2058e1f113209c4f93a4a0f4b2
opw-6520052

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

Forward-Port-Of: odoo/odoo#287882
Forward-Port-Of: odoo/odoo#286781

Currently, an error occurs when opening the Rental Order Lines Schedule view.

**Steps to Reproduce:**

 - Install the `sale_stock_renting` module.
 - Go to `Settings` and enable `Variants`.
 - Go to `Rental` > `Products` and create a product.
 - In the `Attributes & Variants` tab, add an attribute with two values and save.
 - Delete all variants using the `Variants` smart button or from `Inventory` > `Products` > `Product Variants`.
- Return to the `Product` and click the `In Renting smart button`.

`IndexError: list index out of range`

When a product template is created, a product variant is automatically generated if the 
product has no attributes. Deleting this variant also deletes the product template [1].
By explicitly creating attribute values, a dynamic product variant is generated. Deleting 
this variant does not delete the product template because of the dynamic attribute [2]. 
When the In Renting button is clicked, it it going to open the rental order lines Schedule 
view and adds default_product_id to the action context. Since no product variants exist 
anymore, accessing the default product variant raises an error [3].

This commit ensures that default_product_id is not added to the context when the product 
template has no product variants

[1]: https://github.com/odoo/odoo/blob/1f70b81eeebcc62b64c18772915e2f4696e189e7/addons/product/models/product_product.py#L486

[2]: https://github.com/odoo/odoo/blob/1f70b81eeebcc62b64c18772915e2f4696e189e7/addons/product/models/product_product.py#L478-L480

[3]- https://github.com/odoo/enterprise/blob/98ec35f3f17a2b706ad4fcc4d6161d12d05eadfd/sale_renting/models/product_product.py#L69

[4]: https://github.com/odoo/odoo/blob/942d3892c33e7ccdcfec260c3da37095069b699e/addons/stock/models/product.py#L635-L643

[5]: https://github.com/odoo/odoo/blob/942d3892c33e7ccdcfec260c3da37095069b699e/addons/stock/models/product.py#L601-L612

sentry-7637715724

Forward-Port-Of: odoo/enterprise#126356

**Description of the issue/feature this PR addresses:**

When a batch recompute of `vies_valid` contains both a parent (commercial) partner and a child sharing the same VAT, and the child happens to be iterated before its parent, the child ends up with `vies_valid=False` instead of the parent's real, freshly-checked value.

**Current behavior before PR:**

`_compute_vies_valid` loops over `self` in whatever order the batch happens to have:

```python
for partner in self:
    ...
    if partner.parent_id and partner.parent_id.vies_vat_to_check == partner.vies_vat_to_check:
        partner.vies_valid = partner.parent_id.vies_valid
        continue
    status = partner._check_vies_iap()
    partner._update_vies_status(status)
```

`Field.compute_value()` removes the whole batch from the "to compute" queue *before* running this loop (it does so upfront, in case the method does not assign every record). So when the loop reaches a child and reads `partner.parent_id.vies_valid` to reuse it, that field is no longer marked "to compute" for the parent, and reading it just returns whatever is currently cached/stored — which, if the parent has not been processed yet in this same loop, is still the old/default value. The child copies that stale value and, being a stored field, keeps it forever: nothing re-triggers its computation afterwards.

Example:
```python
parent = env['res.partner'].create({'name': 'Parent Co'})
child = env['res.partner'].create({'name': 'Child Address', 'parent_id': parent.id})
child.vat = 'BE0477472701'   # queues the child's compute first
parent.vat = 'BE0477472701'  # queues the parent's compute second
child.vies_valid   # False, even though the VAT is valid
parent.vies_valid  # True
```

**Desired behavior after PR is merged:**

Every partner without a parent is always computed before any child that may reuse its value, regardless of the batch's original order — so the child correctly ends up with the parent's real `vies_valid`.

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

Forward-Port-Of: odoo/odoo#287351
Forward-Port-Of: odoo/odoo#279927

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Forward-Port-Of: odoo/enterprise#132030
Forward-Port-Of: odoo/enterprise#88495

**Steps to reproduce:**
- Install Appointment app
- Create an appointment type based on resources, auto-assigned, with two shareable resources linked together
- Set the first resource's capacity to 3 and the second resource's capacity to 4
- From the backend Gantt view, create a booking for 2 people on the first resource
- Create a second booking for 2 people on the same resource, at the same date and time
- First resource is now overbooked with reserved capacity of 4 out of 3
- Try to create an appointment from the website
- Error: "The capacity reserved should be positive."

**Issue:**
When bookings are created from the backend gantt view, the selected resource can be overbooked even if another linked resource still has available capacity.

Then when trying to book an appointment the new booking lines will trigger this constraint:
```py
_check_capacity_reserved = models.Constraint(
    'CHECK(capacity_reserved >= 0)',
    "The capacity reserved should be positive.",
)
```
This is caused by the negative values in:
```py
booking_line_values = []
if appointment_type.schedule_based_on == 'resources':
    capacity_to_assign = asked_capacity
    for resource in resources:
        resource_remaining_capacity = resources_remaining_capacity.get(resource)
        new_capacity_reserved = min(resource_remaining_capacity, capacity_to_assign, resource.capacity)
        capacity_to_assign -= new_capacity_reserved
        booking_line_values.append({
            'appointment_resource_id': resource.id,
            'capacity_reserved': new_capacity_reserved,
            'capacity_used': new_capacity_reserved if resource.shareable and appointment_type.resource_manage_capacity else resource.capacity,
        })
```

**Fix:**
Avoid negative remaining value in resource booking when computing available slots.

Note: Tried to take the capacity already used by overlapping bookings into account when assigning resource booking lines from the backend gantt view. And also force linked_resources booking when trying to book more
than the total capacity to properly dispatch as many slots as possible. But it was breaking `appointment_google_reserve` tests.

opw-6503147

Forward-Port-Of: odoo/enterprise#131752
Forward-Port-Of: odoo/enterprise#130520

The mobile summary element hides the address form on Android

Steps to reproduce:
1. Install eCommerce
2. On android (or using browserstack) and without being logged in, go to the eCommerce
3. Add any product to the cart and go to checkout
4. Click on "Checkout" to enter the address details
5. Open the keyboard by clicking inside the first input
6. The virtual keyboard opens, enter a name and click on "Next" in the virtual keyboard
7. Do this a couple of times: the cart summary element doesn't scroll and the input field is hidden behind it

Similar problem happens when you scroll a bit after clicking in the first input: the cart summary element displayed at the bottom is still visible (on top of the virtual keyboard) which hides part of the page and makes it difficult to navigate the page and fill in the details

Issue:
`sticky-bottom` keeps the element at the bottom of the screen

Solution:
Remove class `sticky-bottom` from `o_mobile_summary` when we click in one of the input

opw-6500503

Forward-Port-Of: odoo/odoo#287464

### Steps to reproduce

Set a credit limit of 1.000 on a customer, then:

1. Create a Sale Order for a product with Invoice Policy on **Delivered Quantities**, over that amount → the warning shows. Good.
2. Confirm it, and deliver nothing.
3. Create a second order for the same customer → the warning never shows, even though the customer is already over the limit.

### Solution

The ordered quantity is what the customer committed to, delivered or not. Using `qty_to_invoice` instead of `uom_qty_to_consider` or `qty_delivered`

Introducing invoice_status in sales domain for `_compute_credit_to_invoice`: `untaxed_amount_to_invoice` still follows the invoicing policy, while `amount_to_invoice` no longer does. On a confirmed order for a delivery-based product with nothing delivered:

```
    line.untaxed_amount_to_invoice = 0       # still gated by qty_delivered
    line.invoice_status            = 'no'
    order.amount_to_invoice        = 2000    # fixed by this PR
```

The domain filters on the first one, so the order is dropped from the search before its amount is ever read and `credit_to_invoice` stays at 0.`'no'` is the stored marker for a confirmed line that is not invoiceable yet, which is exactly what the first clause misses.

ticket: [6480211](https://www.odoo.com/odoo/project/967/tasks/6480211)

Forward-Port-Of: odoo/odoo#288659
Forward-Port-Of: odoo/odoo#285578

The Time Off Ledger report shows the same "Expected Hours" value for every working day of an employee, even when their working schedule assigns different hours to different weekdays.

### Steps to reproduce:
1) Install hr_holidays_attendance.
2) Create/assign a working schedule where daily hours vary across the
   week (e.g. Monday-Thursday 8.5h, Friday 5h).
3) Go to Attendance > Reporting > Time Off Ledger, filter on that
   employee.

### Observed behavior:
"Expected Hours" is identical on every day (the schedule's average hours/day), regardless of which weekday the row is for.

### Expected behavior:
"Expected Hours" should match the hours actually scheduled for that specific weekday, so a shorter Friday shows less than a full Monday.

### Root cause:
`Time off Ledger` is a SQL view.
Its `_select()` builds `expected_hours` from `rc.hours_per_day` at [1], i.e. `resource.calendar.hours_per_day`, a field explicitly labelled **"Average Hour per Day"** and is computed via [_get_hours_per_day] as `hours_per_week / days_per_week`,
a single flat value for the whole calendar.

The per-weekday hours are available in `resource.calendar.attendance` it stores `dayofweek`, `hour_from`/`hour_to` and a computed `duration_hours` per line, and can legitimately differ per weekday (e.g. Monday 8h vs Friday 4h) at [2]. The report's own [_cte_cal_workday()] CTE already reads this table to decide whether a weekday is a working day (`cal_workday`, joined as `cw` in `_from()`), but discarded the actual hours, keeping only `(calendar_id, dayofweek)`. `_select()` then fell back to the calendar-wide average via `rc.hours_per_day` instead of the per-day value.

Example: calendar with Monday 8h and Tuesday 4h -> `hours_per_day` averages to 6h; the report showed 6h on both Monday and Tuesday instead of 8h and 4h respectively.

[1]- https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L256

[_get_hours_per_day]: https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/resource/models/resource_calendar.py#L703-L707

[2]- https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/resource/models/resource_calendar_attendance.py#L15-L31

[_cte_cal_workday()]: https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L82-L89

### Fix:
`_cte_cal_workday()` now aggregates `SUM(duration_hours)` per `(calendar_id, dayofweek)` from `resource_calendar_attendance`, instead of just selecting the distinct keys. `_select()` reads this per-weekday value (`cw.hours_per_day`) instead of the calendar-wide `rc.hours_per_day` for both `expected_hours` and `difference_hours`.

**opw-6425167**

Forward-Port-Of: odoo/odoo#280664

### Steps To Reproduce:

- Add this content in the HTML editor:
`<h2 class=display-3-fs>heading 2</h2>`
- Select the heading text.
- Click Remove Format.
- Check the font-size input in the toolbar.

### Description of the issue/feature this PR addresses:

- The font-size class was removed from the block element, but the font-size input still displayed the value associated with the removed class.
- The toolbar did not show the correct font size for default block classes (like `o_default_font_size`).
- Applying a new font size inside default block classes created nested spans instead of splitting them.
- The "Remove format" button remained enabled even when selection had no custom formatting (only default block classes).

### Desired behavior after PR is merged:

- The font-size input is updated after removing the font-size class and correctly displays the font size of the resulting block element.
- Update the `getFontSizeDisplayValue` utility to find correct CSS variable dynamically to also find the font size of default block classes.
- Add default font size classes (like `o_default_font_size` and headings) to `format_class_predicates` resource in `font_plugin.js`. This allows them to be split and replaced instead of creating nested spans.

task-6321166

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

Forward-Port-Of: odoo/odoo#272023