Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

__
## Short functional explanation of the error
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B.
In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

## Reproduction Steps
1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check
Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

### Expected behavior
The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

### Unexpected behavior
Nothing happens

## Origin of the issue
When computing the working time to assign, we also take into consideration leaves:
if this happened during public holidays, we consider that it took no working time to get assigned.
However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following:
https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#546

The company isn't taken into account in the domain, applying the holiday for every company.
_________________________________________
opw-5222883

Forward-Port-Of: odoo/odoo#236043

### Description of the issue/feature this PR addresses:

The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed.

If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly.

But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files.
The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment.

I've tested it with double the amount of bytes and it seems to work correctly.

Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details.

### Current behavior before PR:
<img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" />


### Desired behavior after PR is merged:
The uploaded file's mimetype is correctly identified for big (>40mb) open office files.


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

Forward-Port-Of: odoo/odoo#241565
Forward-Port-Of: odoo/odoo#233266

This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets.

**Accordion issues**
How to reproduce: drop two nested `s_accordion` snippets. Then:
1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change,
2. Change the outer "Round Corners" -> both accordion change,
3. Change the outer "Icon Position" ->  both accordion change,
4. Change the outer "Icons" style -> both accordion change.

**Blockquote issues**
How to reproduce: drop two nested `s_blockquote` snippets. Then:
1. Change the outer "Decoration" -> both blockquotes change,
2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too,
3. Change the outer "Author Alignment" -> only the inner blockquote changes.

**Cause**
The above issues occur because certain `applyTo` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited.

**Fix**
The relevant `applyTo` and CSS rules now use more specific selectors.

**Note**
See also https://github.com/odoo/odoo/pull/237733

task-5362171

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

Forward-Port-Of: odoo/enterprise#102910
Forward-Port-Of: odoo/enterprise#102859

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later.

It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this
upgrade script: https://github.com/odoo/upgrade/pull/9153

1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it.
2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout`
3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12
4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore
5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie
6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1

Forward-Port-Of: odoo/odoo#241910
Forward-Port-Of: odoo/odoo#241129

**Descripion of the problems**
When the content of a popup is deleted, two problems happen:
1. The popup stays open displaying an empty white rectangle.
2. Options relative to the last removed element are still displayed and produce an error if the user interacts with them.

**How to reproduce**
Drop the snippet `s_popup`, and remove the "Block" element.
Problems: 1. the popup is still open but empty, 2. the "Block" options are still displayed.

**Origin of the problems**
Problem 1 happens simply because nothing takes care of removing empty popups.
Problem 2 happens because `RemovePlugin.removeCurrentTarget` set the `nextTargetEl` without first checking if the element is activable or not. Thus, when removing the last block in a popup, the next target is set to the `.o_we_no_overlay` close button, despite it being not activable. As a result, when `BuilderOptionsPlugin.updateContainers` is called, it does not update containers because the target is not activable. Thus, the "Block" options are still displayed despite the element being removed.

**Fix**
Both problems are fixed by changing `RemovePlugin.isEmptyAndRemovable` such that empty popups are marked as removable.

task-5401692

Steps To Reproduce
------------------

1- Go to Accounting > Vendors > Bills.
2- Upload a UBL XML file containing both RegistrationName and Contact/Name (you can use one of the two attached in the ticked).
3- Check the Vendor field.

Issue
-----

The vendor name is set to the contact person name instead of the company's legal name.

Cause
-----

In `_import_retrieve_partner_vals`, the XPath prioritizes `cac:Contact//cbc:Name` (contact person) over `cbc:RegistrationName` (company legal name).

Fix
---

Swap the priority to check `RegistrationName` first, falling back to `Contact/Name` only when no registration name exists.

Legal/Standards Proof (OASIS UBL 2.1 Specification) according to sources:

https://www.datypic.com/sc/ubl21/e-cac_PartyLegalEntity.html
- cbc:RegistrationName: "The name of the party as registered with the relevant legal authority."

http://www.datypic.com/sc/ubl21/e-cac_Contact.html
- cac:Contact/cbc:Name: "The name of this contact. It is recommended that this be used for a functional name and not a personal name."

The RegistrationName is the official legal company name, while Contact/Name is just a contact point at the company.

Test
------
For the test I updated a test file so that `test_import_partner_fields` fails without these changes.


opw-5392139

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

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Forward-Port-Of: odoo/enterprise#102364

**Problem:**
When ordering a combo product, you can order more products than the
combo requires, which will the add *base_price* to the combo price.
The problem is that when changing the preset, like going from eat in
to delivery, the pricelist is reconfigured, and it does not take the
extra products from the combo into account. This means that the price
will go back to the combo's price without the extra products.

**Steps to reproduce:**
- Have a combo that can take on multiple free products and has a limit above this free product number
- Order more than the free quantity
- Change the preset (from eat in to delivery)
- The price is recomputed without taking the extra products into account

**Why the fix:**
The extra articles were not accounted for when changing the pricelist,
meaning they would end up free and the price would change. We now
make a separation between the free products (that are from the combo) and
the extra products. The extra products cost the *base_price* of said combo.

To do that, we need to get the extra lines from the combo, which are the
products that are not free in the case where there are more products
selected in the combo than free products defined in the definition of
the combo. To make that happen, we add the non free lines to the
extra lines list once we have at least as many free products as
defined in the combo definition.

In the case where the quantity of a product is greater than the number
of free items, the lines are automatically split. Meaning if we have
a combo with 2 free items but we order 3, we will have a line with
a quantity of 2 and another line with a quantity of 1. In that case,
the first line will be free, but the second line will be an extra.
This logic is implemented here https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/components/popups/combo_configurator_popup/combo_configurator_popup.js#L88-L106
Which is then retrieved here to make the separation in the combo's price
https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/services/pos_store.js#L879

opw-4885574

Forward-Port-Of: odoo/odoo#217082