**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#239648

Message access is notably based on related document, given their
(model, res_id) pair. Model may customize the required access on
it in order to access their message. For example, you generally
need write access to create a message (post) but on some models
you can post when you can read. Calendar events message access depends
on calendar privacy settings.

This is controlled via '_get_mail_message_access'. However currently
it is "globally called", for all documents. It should be done on a
per-document basis, as each document could define different access
check.

Keep code somewhat optimized by doing access checks in batch for a
given operation.

Make _search and read symmetric. Reading documents should be allowed
on search results, and search results should match what is available
for reading.

Portal users have some specific domains applied when accessing
messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for
'website_message_ids' domain, mail controllers, ...). However there
are still some cases where search and read are not coherent with
portal users. This is not really annoying as most messages are accessed
using sudo and correctly tailored domains via controllers but let
us try to have a more correct code.

Fix discuss display of chatter-related buttons
* not taking into account '_get_mail_message_access' to check if
  user has right to post (generally used to indicate users can
  post on readonly records, but not limited to that);
* not adding the same check on Activities button as on Send message
  and Log note. We consider generally that rights should be aligned
  and UX should match that behavior;
* not adding the same check on attachments buttons, currently limited
  to write access (or always accessible). This is a preliminary work
  for attachments, further fixes are probably incoming;

Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 .

Task-5138368
opw-4785878

Forward-Port-Of: odoo/odoo#244129
Forward-Port-Of: odoo/odoo#233725

### Issue:

Applying a push rule in attempt to reach a precise sublocation will not adapt the destination of the move based on the `final_location_id` but solely base the destination based on the push rule.

This is sub-optimal as the existence of an other push rule from this parent location to the sublocation is quite unlikely and validating that new move will therefore not push the product to its `location_final_id`.

### Concrete problematic example:

For instance, the `property_stock_customer` (Customer location) provides a precise `final_dest_id` to deliver the customer. While, in one step delivery (not relying on push mechanic), confirming a delivery will generate a delivery with `location_dest` set to the precise Customer location because of pull rules, in two steps, the final delivery ends up targeting the general `Partner/Customer` location.

This is particularly impactful in case of automatic batching based on destination location.

### Steps to reproduce:

- In the settings enable: Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse to delivery in 2 steps
- Create a contact say BOB and in the sale & purchase tab of its form set the Customer Location to a sublocation of Partners/Customers say: Partners/Customers/BOB
- Create and confirm a sale order for BOB for 1 unit of a any product
- Validate the pick
#### > The delivery and its move have `Partner/Customer` as `move_dest_id`.

### Cause of the issue:

During the `_run_push`, we only adapt the `location_dest_id` to match the `location_final_id` in the case where the new move skip push: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L245 However, in the present case where you push to a parent location of `location_final_id` the move does not `skip_push`: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_move.py#L2034-L2037 and the `location_dest` is the one of the rule:
https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L242 https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L266

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

Forward-Port-Of: odoo/odoo#245314
Forward-Port-Of: odoo/odoo#243828

Description of the issue/feature this PR addresses:
- A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode
- This is because the `applied_on` field is missing on the `product.pricelist.item` form view.

Current behavior before PR:
- Install `sale_management`
- Enable "Pricelist" setting
- Go to Sales - Products - Pricelists and create a new "Sample" Pricelist.
- Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" />
- Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" />
- Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" />
- Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" />
- Same thing for second rule  <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" />
- Create a new sale quotation with pricelist set to our "Sample"
- Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" />
- Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" />
- Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" />


Desired behavior after PR is merged:
- Each variant must have its own price.
- The added test simply edit the pricelist item using its own form.
- The `applied_on` field is added to the pricelist item form to ensure that its value is saved.
- If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column.

_Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?).
But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`.

_Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` ....

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

Forward-Port-Of: odoo/odoo#245444

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105234
Forward-Port-Of: odoo/enterprise#100278

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#104352
Forward-Port-Of: odoo/enterprise#103835