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**

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

## [FIX] l10n_co_reports: fix UNION ALL crash with multiple column groups

### Issue:
Any comparison mode (Period, Analytic, etc.) in the Libro Diario raises an Odoo Server Error

### Cause:
Each sub-query in the `UNION ALL` had its own `ORDER BY` SQL only allows one global `ORDER BY` on a `UNION ALL`, or parentheses around each query — neither was the case

### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Enable Developer Mode in Settings
- Open the Libro Diario report and click the gear icon (top right)
- In the Options tab, enable Period Comparison
- Enable the Comparison for the Previous Period

Before the fix, an error is raised

------------------------------

## [FIX] l10n_co_reports: include partnerless entries in Libro Diario

### Issue:
Journal entries without a partner are excluded from the report but are legally required to appear

### Cause:
`_get_domain` called `super()` which adds `('partner_id', '!=', False)` to the domain, filtering out all partnerless entries
The SQL query also used a `JOIN` instead of `LEFT JOIN` on `res_partner`, excluding lines with no partner at the DB level

### Notes:
`NULL` values for `partner_name` or `line_label` caused the JS to hide the corresponding column headers
`header.js` matches columns to their header by `column_group_index`/`expression_label` and skips `None` values
Fixed by using `COALESCE` to return an empty string instead

### Steps to reproduce:
- Install `l10n_co_reports` and `accountant`
- Create a Journal Entry without a partner or label
- Open the Daily Journal Report

Before the fix, the entry doesn't appear
After the fix, check that PARTNER and LABEL headers are visible

opw-6430728

Forward-Port-Of: odoo/enterprise#129674

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

Steps to reproduce:
----------------------------------------
1. Install the Expense module.
2. Create an expense with a receipt/attachment and approve it.
3. Try to split the approved expense using the "Split Expense" button.

Observation:
----------------------------------------
An Access Error is raised: "You can't add attachments to an expense once it has been approved."

Issue:
----------------------------------------
When splitting an approved expense, Odoo duplicates the original expense into multiple split parts. Since the original expense is already in the `approved` state, the newly created duplicate records also have `state == 'approved'`. During the split process, Odoo copies the attachments from the original expense to the newly created split records:
https://github.com/odoo/odoo/blob/e696bc516c97bc7157d52c5dba0b42e7cb8bab48/addons/hr_expense/wizard/hr_expense_split_wizard.py#L59-L61

Because `copied_expense.state` is 'approved', the create method of `ir.attachment` triggers an AccessError via the security validation https://github.com/odoo/odoo/blob/e696bc516c97bc7157d52c5dba0b42e7cb8bab48/addons/hr_expense/models/ir_attachment.py#L23-L27

Solution:
----------------------------------------
Bypass the attachment restriction if the creation is initiated from the split wizard. It only bypasses the validation during the split operation, preserving the security constraints for normal user uploads to approved expenses

opw-6373579

Steps to reproduce:
- Install `Point of Sale`
- Settings > Invoicing > Taxes > Rounding Method > choose 'Round Per Tax'
- Create 3 products
    - First one costs 16.73 and has 8% sales tax
    - Second one costs 7 and has no applied sales tax
    - Finally, a third one that costs 25.99 and has 8% sales tax too
- Create an order with the following quantities
    - 3 of the first product
    - 3 of the second product
    - 2 of the third one
    _Notice that the total is 131.34, but if you sum the individual lines the total 131.35_
- Go to Reporting > Orders Analysis > pivot view
> Notice that the total price is 131.35, resulting in a discrepancy of 0.01.

### Cause of Issue:
The SQL query that shows the report calculates the prices on a "Round per Line" basis, since it retrives each individual line on its own from `pos_order_line` table https://github.com/odoo/odoo/blob/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/point_of_sale/report/pos_order_report.py#L72 If the order/invoice has products with different taxes, this is bound to cause discrepancies.

### Fix:
Since it is important to match the total value of the order to the total value in the report, while also retriveing the lines one by one, the safest approach was to calculate the tax for each tax group "_round per tax_" and compare it to the tax we get usually by just summing, and if there are any differences we subtract them from the last line of that tax group.

### Drawback:
This might cause some small price differences (in the price's 0.01 places) in different orders, but the display of a correct total value is of more importance.

opw-6141218

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

## Problem

When rendering PDF invoices that contain **section** or **note** lines, the `l10n_gcc_invoice.arabic_english_invoice` QWeb template raises:

```
TypeError: argument of type 'bool' is not iterable
```

This happens because `account.move.line` records of type `line_section` or `line_note` have `name = False`. The template evaluates `arabic_name not in line.name` (and the same for `english_name`), which fails because Python cannot apply the `in` operator on a boolean value.

## Fix

Add a `line.name and` guard before each `not in` check:

```xml
<!-- Before -->
<span t-if="arabic_name not in line.name" .../>
<span t-if="(english_name != arabic_name) and (english_name not in line.name)" .../>

<!-- After -->
<span t-if="line.name and arabic_name not in line.name" .../>
<span t-if="line.name and (english_name != arabic_name) and (english_name not in line.name)" .../>
```

## Steps to reproduce

1. Install `l10n_gcc_invoice` on an Odoo 16.0 instance.
2. Create a customer invoice and add a **Section** line.
3. Print/preview the invoice PDF.
4. Observe `Internal Server Error` / `TypeError: argument of type 'bool' is not iterable`.

Forward-Port-Of: odoo/odoo#278887
Forward-Port-Of: odoo/odoo#267147

### Issue:
On iPhone and iPad (reduced window), the scrollbar is hidden behind the report on long scrollable pages
This affects all browsers on iOS and iPadOS — Apple forces the use of WebKit (its rendering engine) on all of them, including Chrome and Firefox

### Steps to reproduce (on iPhone):
- Install `l10n_es` (contains scrollable reports by default)
- Switch to the ES company
- Open the Tax Report and try to scroll
 
Before the fix, the scrollbar renders behind the report content

### Cause:
`o_content` was added unconditionally in commit https://github.com/odoo/enterprise/commit/d60ea6e0f3245e394fd0cee5f22f52aff2a79e2e
But its role differs between desktop and mobile, and its presence on mobile triggers a WebKit compositor bug

On desktop, `o_content` is required:
`.o_action` stays `overflow: hidden`, so only `.o_content` (`overflow: auto`) can scroll the report
Per the CSS flexbox spec, a flex item won't shrink below its content size unless its `overflow` is not `visible`
Without `o_content`, the div keeps `overflow: visible`, refuses to shrink, overflows `.o_action`, and the excess is silently clipped — content becomes unreachable, not just visually different

On mobile, the framework flips scroll responsibility to `.o_action` (`overflow: auto`) and forces `.o_content` back to `overflow: initial`
`o_content` is therefore not needed on mobile

On WebKit (iOS/iPadOS), keeping `o_content` on mobile is harmful: it sits as a non-scrolling `position: relative` node between the real scroll ancestor (`.o_action`) and descendants that require special compositing — the sticky `thead` and the fixed-position mobile chatter
This configuration causes WebKit's compositor to miscalculate the Root layer bounding box
This geometry mismatch is the most likely explanation for why the native scroll indicator renders behind the report instead of on top of it
Removing `o_content` on mobile avoids this node entirely and restores correct compositor geometry

### Notes:
Tested on Android (Blink) with and without `o_content`: no visual difference and identical compositor layer geometry confirmed via Chrome DevTools — no regression introduced

The `padding-bottom` on `.o_account_report_scroll_container` is unrelated — it is applied unconditionally and exists for a separate bug (last row clipped on scroll)

opw-6191827

### Problem

`l10n_ar_edi` reports WSFEX / WSBFE line quantities (`Pro_qty`) truncated to 2 decimals in 19.0, no matter what precision the database has configured.

`_get_line_details()` reads the precision like this:

```python
uom_precision_digits = min(self.env['decimal.precision'].precision_get('Product Unit of Measure'), 2)
```

In 19.0 that `decimal.precision` record was renamed to **`Product Unit`** (`uom/data/uom_data.xml`, `decimal_product_uom`), so the lookup matches no record. `precision_get` does not raise in that case, it falls back to a default of 2 (`base/models/decimal_precision.py`: `return res[0] if res else 2`), so `min(2, 2) = 2`.

The rename was applied everywhere else — `account.move.line.quantity` already declares `digits='Product Unit'`. Only this lookup kept the old name.

### Impact

A quantity of `0.042` is sent as `0.04`. ARCA rejects the invoice with **error 1815** (item math inconsistency: `unit price x quantity - discount` no longer matches the item total), which blocks export invoicing completely.

It only shows up after upgrading to 19.0: on 18.0 the record still had the old name, so the lookup worked and the configured precision was used.

On our hosted fleet we identified **67 Argentinian databases** that use WSFEX or WSBFE and have a unit precision above 2. Eight of them already run 19.0 and are affected today; the rest will hit the same rejection as they upgrade.

### Fix

Use the current record name, and raise the cap to **6**, the maximum `Pro_qty` accepts according to the WSFEX developer manual ([V3.1.1](https://www.afip.gob.ar/ws/documentacion/manuales/WSFEX-Manualparaeldesarrollador_V3.1.1_ARCA.pdf), p. 15).

### Test plan

`l10n_ar_edi/tests/test_fex.py` adds `test_ar_edi_wsfex_pro_qty_decimal_precision`, covering three cases:

| `Product Unit` | quantity | expected `Pro_qty` |
|---|---|---|
| 3 | 0.042 | `0.042` |
| 2 | 0.042 | `0.04` |
| 8 | 0.1234567 | `0.123457` (capped at 6) |

It does not go through the ARCA mock: it calls `_get_rounded_base_and_tax_lines()` and `_get_line_details()` directly.

### Note

Supersedes #130582 by the same author, which carried the same one-line fix without a test. Please review this one instead.

### Left out on purpose

`price_precision_digits` in the same method caps the unit price at 3 digits, which does not come from the specification either. That lookup still uses a record name that exists (`Product Price`), so there is no regression, and we have no rejection reported because of it. Changing it would widen the scope of a fix that has a concrete incident behind it, so it is left untouched here.

Issue:
Attendance approvers cannot manually adjust the Extra Hours value anymore. The only available workaround is to change the check-in/check-out timestamps, although Extra Hours should be adjustable independently from the actually worked time.

Steps to reproduce:
- Enable overtime validation by manager in Attendances settings.
- Configure an employee with the default overtime ruleset and a standard 40h working schedule.
- Set the Attendance approver to the user used for the test.
- Create an attendance that generates overtime, for example 08:00-20:00 on a regular 8h workday.
- Open the attendance as the approver.
- Try to edit Extra Hours without changing Check In or Check Out.
- Approve the overtime and try to edit Extra Hours again.

Cause:
`validated_overtime_hours` was a readonly computed value based on linked overtime lines, while 
https://github.com/odoo/odoo/blob/ba708ca0cf926a5feaf4b1e50c7d0ead3db4391a/addons/hr_attendance/views/hr_attendance_view.xml#L112-L116

kept the form field readonly. The editable value had moved to `hr.attendance.overtime.line.manual_duration`, but the attendance level Extra Hours field no longer wrote back to it.

Solution:
Make `validated_overtime_hours` editable again and add an inverse function that writes manager edits to non-refused linked overtime lines' `manual_duration`. Keep `overtime_hours`/`duration` computed from the timestamps and rules, and keep the views editable only for managers while the overtime is not refused.

Ignore the default `validated_overtime_hours = 0` sent by form creation, because creating an attendance through the UI does not accidentally override generated overtime, thus we needed to make it readonly when it doesn't have an id yet.

opw-6271244

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

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#284704
Forward-Port-Of: odoo/odoo#283465