Steps to reproduce:
1. Upload an XML invoice (e.g., UBL) containing an embedded PDF into the Documents app.
2. Select the document to open the preview panel.
3. The viewer opens but shows a grey/empty PDF viewer.

Context:
Commit odoo/odoo@5035107e introduced an updated PDF viewer.js. Subsequently, commit d3481a5e removed the `download=0` query parameter from the viewer route to prevent `new URL()` parsing errors on relative paths.

However, the backend specifically relies on the `download=0` flag to intercept the request, extract the Base64 data, and serve the raw PDF binary. Without this parameter, the backend serves the raw XML string directly to the PDF viewer, causing the parser to crash.

Fix:
Restore the `download=0` parameter by using the core `url` utility to construct a safe, absolute URL before encoding it for the viewer. This satisfies the strict `new URL()` parsing in the updated PDF viewer while ensuring the backend correctly triggers the PDF extraction.

Task-6065246

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

This commit:
https://github.com/odoo/odoo/commit/ad6351c

Wrapped the invoice line table in a `<div class="table-responsive-sm">` to enable horizontal scrolling on mobile. However, Bootstrap's `table-responsive-sm` sets `overflow-x:auto` on the container, which prevents wkhtmltopdf from repeating the `<thead>` across page breaks. On pages 2+, the header row (Description, Quantity, Unit Price, Amount) renders on top of the first data row instead of appearing as a separate repeated header.

Made the `table-responsive-sm` class conditional on `report_type == 'html'` so it only applies in HTML views where mobile scrolling is needed, and is omitted for PDF rendering. This follows the same pattern already used throughout the invoice template for other responsive classes.

Steps to reproduce:
1. Create an invoice with enough lines to span multiple pages
2. Print the invoice as PDF

=> On page 2+, the table header overlaps with the first data row, making both unreadable.

Ticket [link](https://www.odoo.com/odoo/action-4043/5867972)
opw-5867972

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

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Forward-Port-Of: odoo/odoo#258234

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#258589
Forward-Port-Of: odoo/odoo#254871

[FIX] purchase: set the correct price in alternative PO
Steps to reproduce the bug:
- Enable "Purchase Alternatives" in settings
- Go to Accounting > Configuration > Taxes:
    - Configure a 15% purchase tax:
    - Advanced Options tab:
    - Included in Price: enabled

- Create a storable product "P1":
    - Tax: 15%
    - In the Purchase tab, add vendors:
        - "Azure Interior": price = $10, min qty = 1
        - "Deco Addict": price = $15, min qty = 1

- Create a purchase order for "Azure Interior":
    - Order 100 units → total price is automatically computed as $1000
- Create an alternative purchase order:
    - Vendor: "Deco Addict"
    - Copy products: enabled

Problem:
The price is $1360, instead of $1500

When the alternative purchase order is created and the product is set
on the purchase order line, the required onchange methods are not
triggered:
https://github.com/odoo/odoo/blob/ad253ef4c2cb06536b99bb919a3e01ed980d2e96/addons/purchase/models/purchase.py#L1169

As a result, both the unit price and the taxes are missing on the
purchase order line. When `_compute_price_unit_and_date_planned_and_name`
is triggered, it attempts to compute the `price_unit`.

https://github.com/odoo/odoo/blob/fb24ad03fc47a303fa8719c0795e1afa9a7eb821/addons/purchase/models/purchase_order_line.py#L345-L346

At this point, it checks whether the purchase order has a vendor.
Since "Deco Addict" is set, it calls `_fix_tax_included_price_company`
using:
- the supplier price ($15)
- the supplier tax (15%)

However, since no taxes are yet set on the purchase order line,
`_fix_tax_included_price_company` incorrectly assumes the price is
tax-included and converts it to a tax-excluded price
(~13.04 instead of 15).

https://github.com/odoo/odoo/blob/7076b4f4d0d933d93b24e8e4c7cf21ef0b0008e5/addons/account/models/account_tax.py#L571-L573

Then, a 15% tax is applied on top of this incorrect base price, leading
to the wrong total.

opw-6047004

Forward-Port-Of: odoo/odoo#258154