When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated.

### Steps to reproduce:

* Create a product A with variants of type never
* Create a sales order with two product A and confirm it
* Go on the delivery (don't validate it) and create a delivery slip
-> Issue, the name of the product appears twice.
* Reduce the quantity of product delivered to one
* Confirm and create a backorder
* Print the deliveryslip
-> Issue, the name of the product appears twice in the backorder section

### Observation:

When confirming the SO:
It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant:
https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300
This information is added to the picking_description (for which the fallback value is the product name):
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340
When printing the delivery_slip, it uses description_picking (and attempts to filter out the name):
https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74
However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name.

The same issue is present here :
https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180

opw-5153222

Forward-Port-Of: odoo/odoo#247610
Forward-Port-Of: odoo/odoo#239693

Currently, an error occurs when user tries to create a new warehouse when Inventory loss stock location is not present.

Steps to replicate:
- Install repairs and enable Storage Locations in settings.  
- Go to `Inventory > Configuration > Locations`, open `Inventory Adjustment`.
- Change the `Location Type` to `Internal` (anything other than `Inventory Loss`).
- Navigate to Warehouses and try to create a new one.

Error:
```
  File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 142, in create
    new_vals = warehouse._create_or_update_sequences_and_picking_types()
  File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 373, in _create_or_update_sequences_and_picking_types
    create_data, max_sequence = self._get_picking_type_create_values(max_sequence)
  File /home/odoo/src/odoo/19.0/addons/repair/models/stock_warehouse.py, line 30, in _get_picking_type_create_values
    scrap_location_id = self.env['stock.location'].search_read([('usage', '=', 'inventory'), ('company_id', 'in', [self.company_id.id, False])], fields=['id'], limit=1)[0].get('id')
IndexError: list index out of range
```

Cause:
- Since the user changed the location type of `Inventory adjustment`, the `search_read()` [1] returned no results and attempting to access its first element causes the error.

Solution:
- Raised a UserError when no Inventory Loss location is found while warehouse creation.

    


[1]: https://github.com/odoo/odoo/blob/62b9f7a81e8d742508d6c80434bb4caf78f9dc65/addons/repair/models/stock_warehouse.py#L30

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

Currently, users can `create` new `Lots/Serial Numbers` directly from the 
Contacts app via the `Lots/Serial Numbers` smart button.

**Steps to reproduce:**
- Install the `stock` and `contacts` modules.
- Enable `Lots & Serial Numbers` from the inventory settings.
- Open the `Contacts` app and open any contact record.
- Click the `Lots/Serial Numbers` smart button.

**Observation:**
The user can `create` a new lot/serial number from the Contacts, even 
though this flow is not supported and results in inconsistent data.

**Root cause:**
After PR [1], `lot/serial number` creation was accidentally enabled from the 
Contact. The intended behavior is that Contacts should only be able to view 
related lots/serial numbers, not create them. (Confirm with PO `crl`)

**Fix:**
This commit disables the creation of Lot/Serial Numbers from the contact by 
`hiding` the New button. This prevents users from creating inconsistent records 
until a complete and correct flow is implemented in a future improvement 
as mentioned at [2].

[1]:
https://github.com/odoo/odoo/pull/184242

[2]:
https://www.odoo.com/mail/message/978482657

opw-5504073

Forward-Port-Of: odoo/odoo#245426

### Steps to reproduce:

- Enable debug mode (to trigger a traceback rather than a silent error)
- In the settings, enable `Work Orders`
- Create an MO for a product without a BoM
- Add an operation to be performed in a workcenter
- Confirm the MO and open the Shop Floor
- Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display
- Click on `Add component` and add any valid component via the catalog

#### > Traceback: `OwlError: Got duplicate key in t-foreach`

### Cause of the issue:

The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72

Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice:
https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188

However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47

Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected.

In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error.

opw-5417887

After this [commit](https://github.com/odoo/enterprise/commit/402ec47), [ec_sales_list_tag_ids](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_return.py#L21) is built by flattening the values of `ec_sales_list_tags_info` using `chain(*values())`.

The tag IDs are fetched from[ _get_tax_tags_for_nl_sales_report()](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_sales_report.py#L75), which returns a dictionary containing:
- a flag (`use_taxes_instead_of_tags = False`)
```.py
(Pdb) ec_sales_list_tags_info
{'goods': [67], 'services': [71], 'triangular': [69], 'use_taxes_instead_of_tags': False}
```
When flattening the dictionary values, `chain` expects all values to be iterable. While the boolean flag is not iterable,
which results in a `TypeError: 'bool' object is not iterable`.

```.py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 493, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
    mod.migrate(cr, installed_version)
  File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
    generate_or_refresh_all_returns(company)
  File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
    self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
  File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
    ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```

In this fix, the boolean flag is removed before chaining since only tag ID lists are needed and the flag causes an error.

Since [1], the voip calls infinite scrolling does not work anymore.

Steps to reproduce:
- Make sure to have at least 14 recent calls
- Open the softphone
- Go to the recent/history tab
- Scroll to the end => You are stuck seeing only the 13 last calls.

This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration.

This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item.

Note that [1] disabled a test that was testing the feature. This commit of course re-enables it.

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd

Forward-Port-Of: odoo/enterprise#106658

# Steps to reproduce
- Open Timesheets
- Go to list view
- Refresh page
- Total is formatted as regular float instead of time

# Cause of the issue
The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget.

Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`).

We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh.

task-5907954

Forward-Port-Of: odoo/enterprise#107203
Forward-Port-Of: odoo/enterprise#107006

Steps to produce:
---
- Install `sale_renting` and `contacts` modules.
- Go to contact and open `yourcompany` record.
- Add a new contact of type Delivery and save (leave the name empty).
- Go to Rental > New Order.
- Select YourCompany, Delivery as the customer.
- Add a rental product and confirm the order.
- Open the Schedule view.

Traceback:
---
`TypeError: sequence item 0: expected str instance, bool found`.

Root cause:
---
- At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence.

Solution:
---
- Use the partner's `display_name` instead of `name`. The `name` field
  can be `False` in some cases. The `display_name` field is a computed
  field that always provides a valid, formatted string by using fallback
  values such as the company name, parent name, or contact type. This
  ensures consistency and prevents errors

[1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61

opw-5914084
---