Steps to reproduce:
- Create a company contact with a delivery address that has no name
- Make a PoS order for the delivery address and pay it
- Open the PoS, open the customer list, and click "Orders" on the company

Issue:
The screen goes blank.

Cause:
The ticket screen is opened with the company name as search term. The server domain searches on `partner_id.complete_name`, so the orders of the address contact are returned too. They are then fuzzy matched on `getPartnerName()`, which returns `false` for a partner without a name, and `fuzzyLookup` calls a string method on it. The error is raised during rendering, so the whole app is destroyed.

Fix:
Make `getPartnerName()` always return a string, and fall back on the parent name, like the complete name does. This way the orders of the address contact are still listed when searching on the company name, instead of being filtered out by an empty name.

opw-6578541

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

Forward-Port-Of: odoo/odoo#288880

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/5661311d55 [REL] 19.1.36 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/95c129db37 [IMP] demo: debounce xml template build [Task: 6574005](https://www.odoo.com/odoo/2328/tasks/6574005)
https://github.com/odoo/o-spreadsheet/commit/b00d61a7f5 [FIX] demo: fix scorecard demo definition [Task: 6573109](https://www.odoo.com/odoo/2328/tasks/6573109)
https://github.com/odoo/o-spreadsheet/commit/54396b9649 [FIX] pivot: wrong running total with collapsed/hidden dimensions [Task: 6569607](https://www.odoo.com/odoo/2328/tasks/6569607)
https://github.com/odoo/o-spreadsheet/commit/bbf0e6ee34 [FIX] pivot: fix scope of `pivot_html_renderer` css [Task: 6523521](https://www.odoo.com/odoo/2328/tasks/6523521)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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

Forward-Port-Of: odoo/odoo#276139

In Ecuador, a company and its branches file under a single RUC, so the
ATS is expected to consolidate all of them. However, currently the
system exports only the active company report.

Steps to reproduce:

- Install the Ecuadorian localization
- Create a parent company and a branch, assign the RUC of the parent to
  the branch, and set the legal name of the branch in Settings
- Post a customer invoice with taxes in the parent (e.g. 750) and
  another one in the branch (e.g. 250)
- Activate both companies in the company selector
- Go to Accounting > Reporting > Tax return
- Select "Report: 104 (EC)", the dashboard shows the consolidated values
- Click on the gear icon next to "Tax Return" and select ATS

Issue:

The exported XML only contains the documents and the totals of the
parent company (750). The branch (250) is omitted.

Analysis:

Currently the ATS export use self.env.company for all searches, which
only retrieve the data of the first company set

opw-6469807

Forward-Port-Of: odoo/enterprise#128430

## [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#131824
Forward-Port-Of: odoo/enterprise#129674

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

Forward-Port-Of: odoo/enterprise#128528