step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

Currently, an error occurs when creating a time off request for an employee.

Steps to Reproduce:

 - Install the `hr_holiday` module.
 - Go to `Management > Time Off`.
 - Create a `new time off` and `remove the start date`.
 - Now `change the employee`.

`AttributeError: 'bool' object has no attribute 'date'`

This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3].

This commit ensures that the system only checks whether the time off is in the past when a start date is provided.

[1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597

[2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279

[3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237

No Task ID

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

Forward-Port-Of: odoo/odoo#238281

## Issue:
When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically
The correct fiscal position only appeared after reloading the checkout page
This issue affects public users using the eCommerce with Stripe Express Checkout

## Cause:
The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself
As a result, prices and taxes were only updated after a full page reload

## Steps to reproduce:
- Configure Stripe with Express Checkout (e.g., Google Pay)
- Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%)
- Create a product using the 15% tax
- Go to the website shop and add the product to the cart
- Use Express Checkout with a US address
- Observe that the fiscal position is not applied unless the page is reloaded

opw-5018238

Forward-Port-Of: odoo/odoo#238690
Forward-Port-Of: odoo/odoo#236832

Step To Reproduce:
- install Project
- login with admin and open any Project settings, say Project 1.
- create a upload document activity for 'marc demo'
- ensure marc demo has 'User' access  for project
-  login with marc demo
- open same project (kanban card -> view)
- upload a document for the created activity

Observation:
-  Traceback

```
TypeError: Cannot destructure property 'id' of '(intermediate value)' as it
is undefined at Activity.onFileUploaded
```
Cause:
- upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model .
- as marc demo does not have write access to this model, no thread is returned
- so `NotFound()` is raised

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55

Fix:
- we check if selected user has appropriate rights or not for upload activity

opw-5160132


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

Forward-Port-Of: odoo/odoo#238360
Forward-Port-Of: odoo/odoo#234936

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

Forward-Port-Of: odoo/odoo#237782

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

Forward-Port-Of: odoo/enterprise#100938

When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled):
- the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version,
- the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version.

Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ...

In the future we would like to handle the received services(formats) on IAP directly to handle change better.

https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50

I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion.

<img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" />

Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json

Forward-Port-Of: odoo/odoo#238674

**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template

**Observation:**
- Traceback for faulty template


**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587

when this content is parsed using DOMParser in browser, 

https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63

we might get different result.
For a very basic template like this:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''" />.
    </t>
    <t t-else="">
        <span>some text</span>
    </t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
    <t t-if="ctx.get('error')">
        <pre t-out="ctx['error'] or ''">.
        <t t-else="">
            <span>some text</span>
    </t>
</pre>
    </t>
</div>
```

Issue roots because of use of self-closing tags, which are valid for xml but not for html

**Fix:**
- we forcefully replace all self-closing tags(which are not void elements)  with a closing tag.
- see  list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element



opw-5234345


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

Forward-Port-Of: odoo/odoo#235924

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#100912
Forward-Port-Of: odoo/enterprise#99774