This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions.

### Steps to reproduce:
1. Install both `stock`, `delivery` and `mrp`
2. Create a product with a kit BOM and weight
   - Set the kit UoM to Unit and the components to Kg
   - Add a weight to the components too
3. Create SO with the kit product
4. Add shipping (UPS)
5. Delivery product
6. `The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure Kg`

The sale price computed in `stock_delivery` does not take kits into account, which leads to conversion of UoM from different products (and therefore different UoM categories).
However, `sale_mrp` already computes the right value for kits.

It worked in earlier versions, thanks to the module loading order, but `_compute_sale_price` moved from the module `delivery` to `stock_delivery`.

Here is the (simplified) module dependency graph:
```
Odoo 16.0:
sale
`-> sale_management
   `-> delivery
`-> sale_stock
   `-> sale_mrp

Odoo 17.0:
sale
`-> delivery
   `-> stock_delivery
`-> sale_stock
  `-> sale_mrp
```

Odoo sorts modules by depth in the graph, and ordered alphabetically for modules with the same depth.
So in Odoo 16.0, `delivery` was loaded before `sale_mrp`, but starting Odoo 17.0, `stock_delivery` is loaded after `sale_mrp` since they both have the same depth.

opw-4385052

Forward-Port-Of: odoo/odoo#206606
Forward-Port-Of: odoo/odoo#190750

**Current behavior:**
With anglo saxon accounting and real-time valuation, purchasing
a kit product with a BoM that has components whose costs add up
to the exact price of the kit product and that is invoiced on
ordered qty and has avg costing, then billing before receiving
will prevent the reception from being validate-able.

**Expected behavior:**
Can validate

**Steps to reproduce:**
1. Create a kit product with avg costing, invoiced on ordered
qty, and a BoM with 2 components that have a cumulative cost
equalling that of the final kit product

2. Make a purchase for it, invoice -> post

3. Try to validate the receipt -> can't due to attempted
re-reconicilation

**Cause of the issue:**
When validating the receipt, we end up here:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L81-L90
And attempt to reconcile both the original kit product AML from
corresponding to the purchase line as well as the AML for the
component in the stock input account.

But we only will capture 1 exploded component AML in each loop
iteration, so the original kit product AML will not actually be
set `reconciled = True`, so we will also add it to be
reconciled again:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L90

The same thing happens in subsequent calls to
`_stock_account_anglo_saxon_reconcile_valuation()`, except on
a final call for the last component line- if the components'
cumulative cost aligns with the total cost of the kit product
(which it should) then the reconciliation attempt will succeed.

Then here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L92
`reconcile()` is called on the already-reconciled AML which will
cause the re-reconiliation error.

**Fix**
Reconcile all the resulting kit AMLs (component AMLs + actual
kit product AML from the bill) together.

opw-4668004

Forward-Port-Of: odoo/odoo#207031
Forward-Port-Of: odoo/odoo#205401

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

When trasnsfering/merging order with some preparation changes, the preparation changes are not correctly transferred to the new order.

Steps to reproduce:
-------------------
* Setup a restaurant with a kitchen printer
* Open PoS restaurant
* Open table 1 add any product and send it to kitchen
* Open table 2 add the same product and send it to kitchen
* Merge table 1 and table 2
> Observation: The preparation change are printed again

Why the fix:
------------
The issue is that the preparation change were not transferred to the new order. This was causing the preparation change to be printed again. I identified 6 use cases to test :
- Transfer sent product on table with same product sent
- Transfer sent product on table with same product not sent
- Transfer sent product on table without the same product
- Transfer not sent product on table with same product not sent
- Transfer not sent product on table with same product sent
- Transfer not sent product on table without the same product

opw-4462713

Forward-Port-Of: odoo/odoo#195843

Otherwise, it will create massive domains, which may exhaust the memory available to PG:

```
 Traceback (most recent call last):
   File "/home/odoo/src/odoo/18.0/odoo/tools/safe_eval.py", line 397, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
   File "ir.actions.server(364,)", line 5, in <module>
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_orderpoint.py", line 257, in action_open_orderpoints
    return self._get_orderpoint_action()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_orderpoint.py", line 500, in _get_orderpoint_action
    qty_by_product_loc, dummy = self.env['product.product'].browse(product_ids)._get_quantity_in_progress(location_ids=location_ids)
   File "/home/odoo/src/odoo/18.0/addons/purchase_stock/models/product.py", line 50, in _get_quantity_in_progress
    groups = self.env['purchase.order.line'].sudo()._read_group(domain,
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1989, in _read_group
    row_values = self.env.execute_query(query.select(*groupby_terms.values(), *select_terms))
   File "/home/odoo/src/odoo/18.0/odoo/api.py", line 978, in execute_query
    self.cr.execute(query)
   File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 572, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 354, in execute
    res = self._obj.execute(query, params)
 psycopg2.errors.SyntaxError: memory exhausted at or near "("
LINE 1: ...((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
                                                             ^
```

upg-2461663

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

Forward-Port-Of: odoo/odoo#207421
Forward-Port-Of: odoo/odoo#202065

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

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

Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id

Actually this is not the case, different upsell order can have a line that have the same parent.

Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B.

Before this commit if the parent line of both order were computed at the same time one of them would end up without parent.

This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched

The follow use case lead to duplicate line on the parent

A parent subscription A with 1 product Z
Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly

Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z

After this commit,
parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time.

Forward-Port-Of: odoo/enterprise#84255

**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
 Traceback (most recent call last):
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
    return _compute_field_value.origin(self, field)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
    partner_tickets.fetch(['stage_id'])  # prevent over-fetching fields, leading to potential out-of-memory error
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
    self.check_access('read')
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
    if not self.env.su and (result := self._check_access(operation)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
    if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
    data = record.mapped(key)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
    recs = recs._fields[name].mapped(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
    self.__get__(first(remaining))
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
    return super().__get__(records, owner)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
    recs._fetch_field(self)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
    self.fetch(fnames)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
   File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
    return [] if self.cr.description is None else self.cr.fetchall()
 MemoryError
 ```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`

Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance

upg-2707381
opw-4653413

Forward-Port-Of: odoo/enterprise#83280

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