When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity from the product's UoM to the order line's UoM. This happens because the product's UoM is not defined.

Steps to reproduce the bug:
- Create a storage “P1”:
    - UoM: Kg

- Create a storable “Kit 1”:
    - UoM: unit
    - BoM:
       - set only the product template field (not the product_id)
        - 1 Kg of P1

- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print

Problem:
A traceback is triggered because we try to convert 1kg to an undefined uom

```
Error while render the template
UserError: The unit of measure Units defined on the order line doesn't
belong to the same category as the unit of measure False defined on
the product. Please correct the unit of measure defined on the order
line or on the product. They should belong to the same category.

```

opw-4619140

Forward-Port-Of: odoo/odoo#205502

During post-install tests, run the following code in a python terminal:

    import socket, time
    with socket.create_connection(('127.0.0.1', 8069)):
        time.sleep(6)

It opens a socket and connect to the running odoo server, but does nothing. After 5 seconds the odoo server closes the socket with a timeout.

The timeout is only set during tests in ``RequestHandler.setup``, and it set to a hardcoded value of 5 seconds. Since Werkzeug 2.1.0[^1], it logs an error in the logs. We want to get rid of that error log.

Those errors can occur when the test chrome browser is killed while it was performing http requests. Chrome doesn't TCP RST the sockets and just let those sockets die.

The socket timeout error actually cannot occurs in production, as all traffic is routed via nginx, and nginx will only proxy the connection to Odoo once nginx has all the requests headers.

That error log is silly, it is now ignored.

[^1]: pallets/werkzeug:d062807

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#204023
Forward-Port-Of: odoo/odoo#203757

Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one.
The issue was introduced in Odoo 18.0 with commit [1].

- Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price).
- That product should be a service one
- Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a variant product that you set there, not a template.
- You should see next to the variant product you just selected a price per booking being displayed. It is correctly showing the product variant price and not the product template price.
- Repeat those 2 steps with the other product variants: create a new appointment and select another variant, you can see the price is correct in the form view.
- Now, go to the website appointment page `/appointment`, you will see that all those appointments will show the same price which is the one from the first variant.
- The same price error will appear once you click on an appointment (you should land on something like `/appointment/4?`)
- Note that if you go further in the appointment booking and land on the shop cart page, the price will be correct there, using the correct variant one. (You'll need to assign a user on the appointment in the backend to be able to book a slot)

Side note: Commit [1] seems to have broken commit [2] too.

[1]: https://github.com/odoo/enterprise/commit/26fb20ace27b7b522a1105c221e4a52cf224a508#diff-5ffc6d13c61e692b22e4c2fec9218cf96c0c86201aeac951ef36e53e7baa7620R4-R9
[2]: https://github.com/odoo/enterprise/commit/5068b0ae7d38cb03318ad1e97124021121fd66cb

opw-4678998

Forward-Port-Of: odoo/enterprise#83104

Description
-----------
When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the
`_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all parent articles in the hierarchy, and only then applies grouping and filtering based on the `id` of `self`. This process includes a `LEFT OUTER JOIN` on related tables to fetch specific `fields` passed as arguments, resulting in an O(n^2) complexity on large tables such as `res.partner` and `knowledge.article.member` (the latter being a Many2many relationship that typically contains a high volume of rows).

This patch improves performance by shifting the grouping and filtering logic to the start of the process, effectively injecting all preconditions at the base of the recursion. This reduces the hierarchy of articles and memberships to explore. Additionally, the computation of inherited permissions—sourced from the "closest" ancestor article—is now handled at the SQL level instead of Python. This eliminates unnecessary rows in the process, avoiding unnecessary work in the business logic afterward.

Benchmark
---------
On a client's database with around 600 articles, 5k partners and 15k knowledge.article.member in total, for a specific article which has a total of 1.7k members (direct and inherited):

| Request                        | Before  | After | Speed-up  |
|--------------------------------|---------|-------|-----------|
| `_get_article_permission_data` | 4.7+min | 150ms | **1880x** |

Reference
---------
opw-4603551

Forward-Port-Of: odoo/enterprise#81264

…mesheet

**Issue**
In a subscription, the qty delivered of a SOL with "Prepaid" invoicing policy
wasn't updated when timesheets were added.

**Steps to reproduce**
1. Have a service subscription product with an invoicing policy "Prepaid/Fixed
price" and creating a task on order.
2. Create a monthly subscription with a start date 15 days in the past
3. Add some timesheet hours on the task.
4. Run the "Subscription: generate recurring invoices" cron.
- Actual: quantity delivered on the SOL stays at 0.
- Expected: timesheet hours falling during the subscription period are added
to the delivered quantity of the line.

**Cause**
Commit https://github.com/odoo/enterprise/commit/a6420bdacab3b9c9f440f48db3b442e6b6c7b655 added a new module overwriting
the computation of the delivered quantitiy for recurring lines based on
timesheets, for products with an invoicing policy `delivered_timesheet`.
However, the computation is overriden for all timesheet lines selected by
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L11-L12

A second filtering is applied later
https://github.com/odoo/enterprise/blob/a6420bdacab3b9c9f440f48db3b442e6b6c7b655/sale_subscription_timesheet/models/sale_order_line.py#L21
Which exluces products with an invoicing policy different than
`delivered_timesheet`

**Solution**
For products with a "prepaid" invoicing policy, compute the delivered
quantities the same way: the timesheets delivered during the subscription
period.
Note that as explained in a comment, `Side effect: It won't work for the
first period if the invoice cron never run. (the next invoice date has never
been incremented)`

opw-4509495

Forward-Port-Of: odoo/enterprise#82806