Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112948
Forward-Port-Of: odoo/enterprise#103950

*: stock_barcode_mrp, stock_barcode_picking_batch

## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.

## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
     - Delivery Orders.
     - Manufacturing Orders
     - Batch Pickings
     - Inventory Count
- From any of these open a record
  (e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.

## Cause of the Issue:
- When switching views inside the Barcode client action,
  the FormController calls `setDisplayName(this.displayName())`.
  In some cases, this returns an empty string, overwriting the
  previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
  preventing the controller from retrieving a proper name.

## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.

TaskID: 4978997

Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165

Steps to reproduce:
-------------------
1. Install Timesheets and Time Off.
2. Create a new Time Off type with duration type "Half Day"
(disable "Require allocation" to skip allocations).
3. Enable "Timesheets" in Timesheets > Configuration.
4. Ensure the employee is configured with a "Flexible" working schedule.
5. Create a multi-day Time Off request (2 days) using this type and approve it.
6. Check the timesheet entries for the employee.

Issue:
------
When a multi-day time off request is submitted for a "Half Day" time off type,
the system fails to generate individual daily timesheet entries. Instead, it generates
a single timesheet entry with a duration calculated as leave_version_sudo.hours_per_day / 2,
regardless of the actual number of days requested.

(e.g., if hours_per_day is 8, it generates one entry of 4 hours for a 2-day leave),

Cause:
------
After this commit 9512832, multi-day requests were allowed for time off types
where the **request_unit** is "half day" or "hours". However, the logic in `_generate_timesheets`
for flexible calendars was not updated to account for this.

if `work_entry_type_request_unit == 'half_day'`, the following condition in
`_generate_timesheets`:
https://github.com/odoo/odoo/blob/6ec97349d998701373920b883a95be7132648e03/addons/project_timesheet_holidays/models/hr_leave.py#L45
always evaluates to True. This traps multi-day requests in the "single-day"
logic, preventing the code from reaching `_list_work_time_per_day`.


Solution:
---------
Update the condition to strictly check if the request is a single day before applying
the simplified single-entry logic. If the request spans multiple days, it will now
correctly fall into the else block, utilizing `_list_work_time_per_day` to generate
one timesheet entry per day of the leave.

opw-5715197



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

Forward-Port-Of: odoo/odoo#257456
Forward-Port-Of: odoo/odoo#248605

**Steps to reproduce:**
- Create 2 products, set their price to 0
- Create a combo product, set it's price to 10
- The combo choices should be the 2 products created before
- Go to the self order, order the combo and change the qty to 3
- The price is 30, correct in the frontend
- Go to the order in the backend, the price is 0

**Why the fix:**

In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines.
This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code
https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 
But the total price has been computed to zero, so the previously computed price_unit is overriden and set to zero.

We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line.

The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation.

opw-6032408

Forward-Port-Of: odoo/odoo#254443