Currently, an exception is generated when the system tries to find the product category after all product categories have been deleted.

Steps to reproduce:

1. Install the `point_of_sale` module without demo data.
2. Navigate to Inventory -> Configuration -> Categories.
3. Delete all categories.
4. Navigate to Point of Sale -> load sample of furniture, bakery or restaurant shop
5. An error occurs.

Error:
```
ParseError
while parsing /home/odoo/src/odoo/saas-18.2/addons/product/data/product_demo.xml:10, somewhere inside
```
This issue[1] occurs because when the system tries to reference the missing product category, it results in a ParseError due to a missing required record.

[1] - https://github.com/odoo/odoo/blob/6c01e3994fab23ff1b23da807ecb0bf551066816/addons/product/data/product_demo.xml#L10-L16

This fix resolves the issue by returning False when the reference product category is missing.

sentry-6251128895

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

Forward-Port-Of: odoo/odoo#202516

Steps to reproduce:
Using POS configs in french company with l10n_fr_post_cert module installed.
- Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment.
- Cash desk 2: Prepare an order
- Cash-desk 1: Start order payment.
- Cash-desk 2: Start order payment while cash-desk 1 is still paying.

Issue:
When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries.

Task-4708543

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#207555
Forward-Port-Of: odoo/odoo#205935

This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses.
This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed.

To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields linked to customers. In the case of the above models, we don't want to send a message to all the attendees (they were stored in partner_ids which is the default field read). Thus by returning an empty list we block the computation of suggested_recipients and default_recipients. Letting full control to the user sending the email which people to notify.

task-4736015

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

Forward-Port-Of: odoo/odoo#207155
Forward-Port-Of: odoo/odoo#206474

The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.

## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg

OPW-4734980

---

Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
    self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
 ```

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

Forward-Port-Of: odoo/odoo#207401
Forward-Port-Of: odoo/odoo#206884

Versions
--------
- saas-17.4+

Steps
-----
1. Create a SO for non-user client;
2. add a product that isn't published on the website;
3. confirm SO;
4. create downpayment;
5. copy share SO link;
6. open link in private window.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> ValueError: Expected singleton: product.product()

Cause
-----
Commit 9aa52dd6418e removed the creation of a "Down payment" product. Before it, order lines were either of type `display_section` or they had a `product_id` value. After the commit, a third option is for `is_downpayment` to be true.

This regressed the fix to this issue added by 34d4ffa01d57d, as instead of ensuring lines have a `product_id` value before checking if reorder is allowed, it decided to check whether they're not of `display_type`.

Solution
--------
Ensure there's a `product_id` in `sale.order.line` instead of only relying on the caller to filter those out beforehand.

opw-4711297

Forward-Port-Of: odoo/odoo#207772
Forward-Port-Of: odoo/odoo#206435

Currently an exception was generated when the user tries to save the new employee record after clicking on call icon.

Steps to reproduce:
1) Install HR module
2) Create a new employee record by giving employee name 
3) Click on the call icon of work phone
4) Now tries to save the new employee record

Error: `KeyError:  name`

This issue occurs because, while clicking the call widget, it creates the record but does not update it in the browser.

As a result, when the user tries to save manually, It again  creates the record with an empty vals_list.

So it will leads to the above traceback from the below lines

https://github.com/odoo/odoo/blob/2d64d94487d24278dc3c6615343a793e1ec94daf/addons/hr/models/hr_employee.py#L386

This fix resolves the issue by ensuring that clicking the call icon before saving retains the user input. Additionally, I have added a test to verify this behavior.

sentry-6234873849

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

Forward-Port-Of: odoo/odoo#206710
Forward-Port-Of: odoo/odoo#195278

**Steps to Reproduce:**
- Go to Sales
- Make a user-defined filter and make it the default filter
- Try to access the JSON link (/json/sales)
- You will see an error

**Issue:**
- When users apply default filters like 'My Quotations' or 'My Documents', Odoo saves 'uid' in the filter's domain to represent the logged-in user.
- However, when the system tries to process this filter, it fails because 'uid' is just a placeholder and not a valid value. This results in an **internal server error**, preventing users from applying these filters correctly.

**Cause:**
This issue is caused after this commit: https://github.com/odoo/odoo/pull/182196
- The domain string stored in 'ir.filters' includes 'uid' instead of the actual user ID.
- When Odoo('ast.literal_eval()') tries to evaluate the filter, it doesn’t know what 'uid' means, causing an error.

**Fix:**
- Replace 'uid' with `str(model.env.uid)` before evaluating the domain.
- This ensures 'ast.literal_eval()' processes a valid domain.

**Affected version:** 18.0~master
**opw**-4645608

Forward-Port-Of: odoo/odoo#202890

XLS(X) allows to store in cells date/datetimes values as date/datetime objects. Meaning, instead of having a string with the date in some format, the cell value can hold an actual date/datetime object, which are automatically converted into the `datetime.date`/`datetime.datetime` when the xls(x) file is parsed in python.

When an xls(X) file contains at the same time date values under date/datetime objects and under strings with the user format `%d/%m/%Y` (rather than the server format `%Y-%m-%d`),
the import was failing with the error
`time data '06/30/2025' does not match format '%Y-%m-%d'`

This error normally happens when the user tries to do an import with different kind of date formats under strings in the same file e.g. `06/30/2025` and `2025-07-01`
and this is understandable that Odoo doesn't know what to do in such a case.
But, if you stick to the same format, either only `%d/%m/%Y` either only '%Y-%m-%d'`, Odoo supports it.

However the case here is trickier: it's when the file contains at the same time dates under a string format, e.g. `06/30/2025` and under date objects, e.g. `datetime.date(2025, 6, 30)`. Which can happen quite easily, as Google Spreadsheet for instance tends to automatically convert the cells holding a date value into date object. And it's then easy to have a file containing both date objects and strings for date, which looks visually the same in the Google Spreadsheet interface.

In addition Google Spreadsheet tends to convert automatically only dates below the 12 of the month because of the american format. e.g.
if you set `01/06/2025`, it gets converted into a datetime object if you set `13/06/2025`, it doesn't get converted into a datetime object, the value stays as a string.

The goal of this revision is to support to have the possibility of having date values under date objects and string in a user format

The problem lied in the fact, during the xls parsing, date objects were converted into strings using the server date format. And then you could finish with data containing both the user format and the server format.

The idea is to no longer automatically convert date objects and to support having date objects in the import parsing. And when trying to guess the date/datetime format of the file, date objects are simply ignored, as they do not need to be parsed.

Forward-Port-Of: odoo/odoo#206876

Before this commit, achievement were performed using records on
account_move, sale_order and sale_order_log tables (+ move lines, order
lines, products etc).

Reading those table is extermely costly. We tried to limit what we
fetched using context depending on the current action:

- https://github.com/odoo/enterprise/commit/7c8621e71b1e8267cd6e0e7968cbb46705568e32
- https://github.com/odoo/enterprise/pull/80043

And we had to revert it here:
https://github.com/odoo/enterprise/commit/c6ee48faa967342c958b4410e71b49bf453cd316

Using a period_domain in the context computed on fly in _where_calc was
a bad idea. The record were correctly fetched but the following flow was
broken:

Go to an approved commission plan --> click on the commissions stat
button --> everything is correct
Now click on details for a commission line with non empty achived amount

All the achievements are correct but when we click on "Details" of
sale.commission.achievement.report (id=42) account_move (142), we may
end up on another record.

Because when the ORM does the fetch query, it will fetch
sale.commission.achievement.report where id=42 and at that moment, the
context is lost when we click on the line.

Therefore as ids are recomputed, the line 42 is not the one
corresponding to the account move 142 anymore.

This commit ensure we avoid doing a cross join on account_move or
sale_order or sale_order_log because these are really bad for
performance and we select the record in a CTE.
- We select them based on current users, teams if defined
- We avoid fetching records outside of plan date values

Forward-Port-Of: odoo/enterprise#82518

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#83555
Forward-Port-Of: odoo/enterprise#81818

### 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

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#81440
Forward-Port-Of: odoo/enterprise#79255

Currently, when validating multiple deliveries at once for which at least two are from the same sale order, the related shipping labels are getting printed multiple times.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Duplicate the delivery
* Validate both deliveries delivery
> Observation: I have 4 jobs send for printing instead of 2

Why the fix:
------------
Actually the issue has the same explanation as this commit https://github.com/odoo/enterprise/commit/34267c4fa8c9aaa7c0216de13111a81fb53a67f1

as the IoT overrides `message_post` to send printing jobs each time a message is posted in the chatter.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L30-L46

opw-4526013

Forward-Port-Of: odoo/enterprise#82091

When the user tries to reply a whatsapp message,
a traceback will appear.

Steps to reproduce the Error:
- Install ``whatsapp`` and ``contacts`` module
- Go to WhatsApp > Configuration > WhatsApp Business Account >
  create a new account > Default Users: Mitchell Admin > Save
- Go to Contacts > Open Mitchell Admin > Set Phone > Click on Whatsapp >
  Send a message with any template
- Contact will receive the message > Reply to that whatsapp message

Traceback:
```
UniqueViolation
duplicate key value violates unique constraint "discuss_channel_member_partner_unique"
DETAIL:  Key (channel_id, partner_id)=(84, 175) already exists.
```

https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L250 At lines [1] and [2], the same partner(s) (e.g., Mitchell Admin) are added to
``partners_to_notify`` multiple times.
Channel members should be unique.
So, when it tries to create ``channel_member_ids`` with same partners,
It will lead to the above traceback.

1- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L219

2- https://github.com/odoo/enterprise/blob/daac4da302e63f87fe3f244099e26b47d08d7cfb/whatsapp/models/discuss_channel.py#L249

sentry-6252537579

Forward-Port-Of: odoo/enterprise#83908