In certain conditions all lines in invoice require a tax. When making
a down payment from an order containing products using fixed price tax,
the corresponding invoice line was created without tax. The issue appear
both when making the down payment from the sale order and from the PoS.

Steps to reproduce:
-------------------
* Create a fixed price tax of 10€
* Create a product with this tax
* Create a sale order with this product and make a downpayment of 10%
> Observation: The down payment line has no tax set.
* Open PoS and make a down payment of 10% for the same order
* Pay and invoice the order
> Observation: The down payment line has no tax set.

Why the fix:
------------
If the tax is required on every invoice line we manually add a 0% tax to
the down payment line to ensure that the invoice is compliant.

At the moment we only add the tax when peppol is activated on the
current company. But the `_require_tax_ids_on_invoice_lines` method can
be overriden by other modules if downpayment lines also require tax.

opw-5853070

Forward-Port-Of: odoo/odoo#251650
Forward-Port-Of: odoo/odoo#247748

### Issue:
No tax will be applied if in taxes, fiscal position is set to all.

#### Steps to reproduce:
1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder.
2- Set Domestic FP to be applied automatically, and set the country to `US`.
3- Create a Partner with `US` country_id.
4- Create a product, and apply the created tax to sale taxes.
5- Create a SO with created partner and the created product.
6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic.

Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp.

### Cause:
In this line, if no `tax_ids` is set, it means fp has not tax_ids:
https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158

However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation.

In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped.

### Fix:
This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set.

### Remark:
In this fix we rename `TestInvoiceTaxes._create_invoice` to `_create_invoice_taxes_per_line` to avoid override of `AccountTestInvoicingCommon._create_invoice`. This is already done on saas-19.1+.

opw-5463245

Forward-Port-Of: odoo/odoo#244155

You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected.

Steps to reproduce
1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b),
model_b.x_studio_test(relation=other_model)`.
2. Create a related field on model_a and click the related icon for the test field.
3. The popover will now be displaying the fields for other_model instead of model_b.

Cause:
This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). 

Solution:
Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`.

opw-ticket 5459944

Forward-Port-Of: odoo/odoo#249185

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Forward-Port-Of: odoo/odoo#246995

**Problem:**
When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results.
When the filter is 'set' it returns all records (even the ones without an analytic distribution) and when the filter is 'not set' it returns no records (even the ones without an analytic distribution).

**Steps to reproduce:**
1) Go to Accounting > Journal Entries.
2) Apply a filter for Invoice lines > Distribution Analytic Account.
3) Select "is set" or "is not set".
4) Check records.

Issue is also reproduceable on Purchase Orders.

**Cause:**
The `_search_analytic_distribution` method did not correctly handle the case when the value is [False], so it results in an invalid Query.

**Solution:**
- We need to handle the case when we have False in the value on it's own.

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

Forward-Port-Of: odoo/odoo#251096
Forward-Port-Of: odoo/odoo#247777

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.


opw-4879481

Forward-Port-Of: odoo/odoo#251580
Forward-Port-Of: odoo/odoo#245741

### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.

### Steps to reproduce:
- Create a new work schedule:
    - Flexible Hours
    - 24 hours per week
    - 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out

### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).

### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.

To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.

Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.

In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.

In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.

Forward-Port-Of: odoo/enterprise#109281
Forward-Port-Of: odoo/enterprise#105521