Currently a `ParseError` arises when we try to load the store data after deleting the `Food` Category in Invoicing.

Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Categories > Delete `Food`
- Now in POS try to load `Restaurant` and `Bar`

Traceback:
---
```
ValueError: External ID not found in the system: point_of_sale.product_category_food

ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_restaurant/data/scenarios/restaurant_data.xml:56, somewhere inside <record model="product.product" id="pos_food_bacon">
            <field name="name">Bacon Burger</field>
            <field name="list_price">15.50</field>
            <field name="standard_price">13.95</field>
            <field name="description_sale">200G Irish Black Angus beef, caramelized onions with paprika, chopped iceberg salad, red onions, grilled bacon, tomato sauce, pickles, barbecue sauce</field>
            <field name="type">consu</field>
            <field name="weight">0.01</field>
            <field name="uom_id" ref="uom.product_uom_unit"/>
            <field name="image_1920" type="base64" file="pos_restaurant/static/img/th-burger.png"/>
            <field name="available_in_pos" eval="True"/>
            <field name="categ_id" ref="point_of_sale.product_category_food"/>
            <field name="pos_categ_ids" eval="[(6, 0, [ref('food')])]"/>
        </record>
```

The error occurs because the user deleted the category, and then tried to load the store data, that references the missing product category.

This commit resolves the error by providing a False value for the field if the product category is missing.

sentry-6314696040

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

### Steps to reproduce:
	- Create a leave type that creates timesheet
	- Create a leave for a flexible employee for 4 days
	- Check the timesheet created for this leave
	- Notice the amount of this timesheet is 83 hours not 32

### Cause:
When creating a timesheet or a work entry for a leave we get the difference between the start and the end date in milliseconds and divide it by 3600 to get the hours.

Timesheet:

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_mixin.py#L208-L213

Work entry:

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L522-L525

This doesn't work for flexible hours as when fetching attendance intervals for flexible employee we return one big block for the whole period as there is no attendance intervals for the flexible employees.

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L370-L376

### Fix:
When fetching the attendance intervals for flexible employee we return the hours per day as duration hours not the diff between the start and the end date of the period. We only use the diff between the dates in case of fully flexible. Then we use this duration hours in timesheet and work entry creation

opw-4628296

Forward-Port-Of: odoo/odoo#206252

## Description
I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records.

Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products).

Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This computed field is always triggered during incoming stock transactions when calculating the average cost or fixing rounding errors.

## Proposal
To improve performance, I propose implementing a Parallel Index-Only Scan. This method is effective for grouping large datasets while retrieving only fixed columns, optimizing query execution.

## Benchmark
| Before | After | Speedup |
|--------|--------|--------|
| 1.1 s| 97.8 ms | 11x| 

### Before
```
Finalize GroupAggregate  (cost=1000.56..397852.39 rows=538 width=80) (actual time=1040.355..1114.694 rows=1 loops=1)
  Group Key: product_id
  Buffers: shared hit=227534 read=330906 dirtied=83 written=683
  ->  Gather  (cost=1000.56..397825.49 rows=1076 width=80) (actual time=1039.900..1114.679 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        Buffers: shared hit=227534 read=330906 dirtied=83 written=683
        ->  Partial GroupAggregate  (cost=0.56..396717.89 rows=538 width=80) (actual time=1036.758..1036.759 rows=1 loops=3)
              Group Key: product_id
              Buffers: shared hit=227534 read=330906 dirtied=83 written=683
              ->  Parallel Index Scan using stock_valuation_layer_index on stock_valuation_layer  
                    (cost=0.56..392927.16 rows=302613 width=20) (actual time=0.608..975.431 rows=247487 loops=3)
                    Index Cond: ((product_id = 140) AND (company_id = 1))
                    Buffers: shared hit=227534 read=330906 dirtied=83 written=683
Planning:
  Buffers: shared hit=9 dirtied=1
Planning Time: 0.139 ms
Execution Time: 1114.732 ms
``` 

### After
```
Finalize GroupAggregate  (cost=1000.56..21876.83 rows=538 width=80) (actual time=91.888..97.719 rows=1 loops=1)
  Group Key: product_id
  Buffers: shared hit=12889 read=7121
  ->  Gather  (cost=1000.56..21849.93 rows=1076 width=80) (actual time=91.636..97.704 rows=3 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        Buffers: shared hit=12889 read=7121
        ->  Partial GroupAggregate  (cost=0.56..20742.33 rows=538 width=80) (actual time=87.579..87.580 rows=1 loops=3)
              Group Key: product_id
              Buffers: shared hit=12889 read=7121
              ->  Parallel Index Only Scan using idx_svl_company_product on stock_valuation_layer  
                    (cost=0.56..16951.60 rows=302613 width=20) (actual time=0.044..46.642 rows=247487 loops=3)
                    Index Cond: ((company_id = 1) AND (product_id = 140))
                    Heap Fetches: 9188
                    Buffers: shared hit=12889 read=7121
Planning Time: 0.107 ms
Execution Time: 97.751 ms
``` 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#206587
Forward-Port-Of: odoo/odoo#203038

Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request.
This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test.

Checking the logs:

2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow
2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced

That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome.

It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank

2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage

It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between
the cookies are cleared and the page navigates to about:blank.

One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class.

It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore.

Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open

Combining both solution should hopefully highly reduce this error. 

A final decision was made to also forbid any request coming after a browser_js.
- browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result.
- After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness.

Note: The explicit deletion of the session cookie is also removed, it is not  needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error.
@xmo-odoo  ping

Forward-Port-Of: odoo/odoo#206709
Forward-Port-Of: odoo/odoo#206006

This commit fixes the following two issues in the menu creation dialog:

**Issue 1:**

- Install the Website app and go to the homepage.
- In the backend navbar, click on "Site" and then on "Menu Editor."
- Drag a menu item (without dropping it) to the right to create a sub-menu.
- The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and unclear from a UX perspective.

| BEFORE  | AFTER |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/7b89bde2-2b22-4d9c-9665-078bb0906e26)  | ![image](https://github.com/user-attachments/assets/d9cf0b4f-3d5c-4d33-ba3c-08756d580f20)  |

----------------

**Issue 2:**

- Install the Website app and go to the homepage.
- In the backend navbar, click on "Site" and then on "Menu Editor."
- Drag and drop the second menu item to the right to create a sub-menu.
- Drag another menu item (without dropping it) to the right to create a second sub-menu below the first one.
- Without releasing it, continue dragging it to the right.
- The issue is that the placeholder disappears at this point. To make it reappear, the menu item must be moved slightly to the left again. This results in a very poor user experience and makes sub-menu creation messy.

| BEFORE  | AFTER |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/694d89d1-4391-4ffa-bb5e-21f8d6b1ffc3)  | ![image](https://github.com/user-attachments/assets/2c5e25d4-996a-4fde-9ed0-a52e1ed60923)  |

task-4422810

Forward-Port-Of: odoo/odoo#204436

Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4

**Steps to reproduce the bug:**
- Install the “Sales” module.
- Do not enable the "Units of Measure" option in the settings.
- Create a new quotation.
- In the sale order line, enable the Product Variant field.
- Try to create a new “product.product”

**Problem:**
A validation Error is triggered:

```
The operation cannot be completed
 - Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.

Model: Product (product.template) Field: Unit of Measure (uom_id)

```
**Explanation:**
This happens because a default value for the UoM is passed through the
context. As a result, we skip the computation of “uom_id”:
https://github.com/odoo/odoo/blob/2b38c1f446441e04f8d85125a9ec6562d13b7ce8/addons/product/models/product_template.py#L27

However, this default is derived from the field “product_uom” that is
present in the view but restricted to users in the "uom.group_uom"
group. If the current user doesn't belong to this group (if you don't
enable the param in the settings), the field is hidden and its value is
empty, causing the default to be set to False.

https://github.com/odoo/odoo/blob/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4/addons/sale/views/sale_order_views.xml#L537


**Solution:**
Force the computation of “uom_id” by removing “default_uom_id” from the
context when its value is “False”.

opw-4717913

Forward-Port-Of: odoo/odoo#205881

**Problem:**
When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account.

**Steps to reproduce:**
- Make a Sale Order in the sales app
- Go to POS and make a down payment for it.
- Settle the order
- See that the down payment has not been applied and only the product is present

**Why the fix:**
When reading the order we are trying to settle from the backend we also trigger the `missingRecursive` function as the lines corresponding to the downpayment line and the line sections were missing from the loaded records.

`sale.order.line` records are thus read from the backend but are not linked back to the sale order leading to the missing lines on the pos order as well.

opw-4718691

Forward-Port-Of: odoo/odoo#206638

This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image.

Steps to Reproduce:

 - Install the `web` module.
 - Go to `Settings`.
 - In the `companies` section, under Your Company, click on `Update Info`.
 - Upload an image with dimensions width = 8 and height = 901.
 - Go back, and in the Companies section, click `Configure Document Layout`.

ValueError: height and width must be > 0

This error is due to the current logic in `base_document_layout.py`, where the width (w) is computed using int(50 * base_w / base_h). For highly vertical images (e.g., width = 8, height = 901), this calculation results in w = 0, which subsequently causes a ValueError when passed to the resize() function.

This commit resolves the error by using `math.ceil` to compute the width (w) instead of int, ensuring that the value is never zero, even for extremely vertical images.

Sentry-6516888945

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

Forward-Port-Of: odoo/odoo#205017

**Steps to reproduce:**
- Install Accounting and Studio

- Go to "Accounting / Customers / Invoices"
- Enable Studio and go to "Reports" tab
- Duplicate "Invoices without Payment" report
- Note the id of this custom report (e.g. account.report_invoice_copy_1)

- Go to "Settings / Technical / Email / Email Templates"
- Open "Invoice: Sending"
- In "Settings" tab, set the custom report as dynamic report

- Go to "Settings / Technical / Parameters / System Parameters"
- Add a new parameter:
  * Key: account.custom_templates_facturx_list
  * Value: [id of the custom report] (e.g. account.report_invoice_copy_1)

- Create an invoice
- Confirm the invoice
- Send the the invoice via "Send & Print" button
- Check the attached PDF

**Issue:**
2 PDF are sent: the default invoice report and the custom one as configured on the email template.
The default one has the factur-x version embedded in it, but not the custom one.

**Cause:**
The hook that embed factur-x into the PDF is called after the creation of the default PDF report.
The custom reports (i.e. the dynamic ones) are created afterwards.
However, the code that should trigger the hook for these ones is only doing it when coming from "Print" action and not from "Send & Print" action.

**Solution:**
Also trigger the hook to embed factur-x in custom report when using "Send & Print" action.

opw-4645564



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

Forward-Port-Of: odoo/odoo#206763
Forward-Port-Of: odoo/odoo#204588

### Steps to reproduce:
- Accounting > Journals > Bank
- Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments"
- Create a payment with a partner
- Confirm it, its state should be "Paid"
- Create an invoice with the same partner and amount
- Confirm and click the add button to link the payment
- Return on the payment, its state is back to "In Process"

### Cause:
This [commit](https://github.com/odoo/odoo/commit/533984ac5c10fbd91742f34b740c63c04fbef094) added the return to the state "In process" when payment are unreconciled. The check is:
`if move.currency_id.is_zero(sum(liquidity.mapped('amount_residual')))`
 
When setting the journal "Bank" as the outstanding account, the line which appear in `liquidity` has the payment amount in `amount_currency` and `amount_residual`. So the amount is not 0 and the payment state is set back to "In Process".

### Solution:
When the account of the payment does not allow reconciliation, the payment is never supposed to be in the state "In Process". To prevent this, this commit adds a check on `account_id.reconcile`.

opw-4718717

Forward-Port-Of: odoo/odoo#206447

### Issue:

Although Fedex's API shoud accept GBP's UK currency for rate requests, you will raise a `CURRENCY.TYPE.INVALID` error from Fedex if you try to get the shipping rate for an order whose currency is GBP.

### Steps to reproduce:

- Install UK accounting and select UK's company: the currency will be GBP
- Install and set up Fedex Integration
- Configure the Fedex in the delivery method, FEDEX_YOU_PACKAGE and Fedex priority for package type and service type
- Create a sale order, add shipping and get the shipping rate for your set up fedex UK.
#### > Fedex request error: `CURRENCY.TYPE.INVALID`

### Cause of the issue:

The currency used in the fedex request is the currency of the order: https://github.com/odoo/enterprise/blob/07845988daad911b10de3b7199b81cc4ed3cfba9/delivery_fedex_rest/models/delivery_fedex.py#L133-L141 that is GBP, however since 44e32359bb79eed08a41861e155c98f664c6d09a we do not automatically convert the GBP currency in UKL. Since Fedex API does not seem to support the GBP we raise the error.

### Fix:

We should use the currency conversion available between GBP and UKL.

opw-4712354

Forward-Port-Of: odoo/enterprise#83388