**Steps to produce:**
- Install project module.
- Go to project > Open any project > Open any task > Click on gear icon.
- Click on Add properies > Set Field type as `Many2one` and Model as `Contact`.
- Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`.

**Issue:**
- The assigned value disappears after saving.

**Root cause:**
- At [1], since `id` is not an active field (see [2]), it is not present in
  record.data, which is expected. However, record.data is then passed to
  m2oTupleFromData, which assumes that the data includes an id because it is
  normally used on data coming directly from the ORM.
- Additionally, since display_name is also not present, m2oTupleFromData falls
  back to record.data.name, which is not proper.

**Solution:**
- Use an ORM read to retrieve the proper display_name of the record before
  constructing the Many2one tuple.

[1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89
[2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795


Before:
<img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" />

After:
<img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" />


**opw-5257819**



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

Forward-Port-Of: odoo/odoo#240443
Forward-Port-Of: odoo/odoo#238052

Steps to reproduce:
===================
- Install an RTL language (e.g., Arabic) on the website.
- Go to website & Edit mode
- Drop product snippet `s_dynamic_snippet_products`.

->When the website is viewed in an RTL language, the navigation arrows
in the snippet are displayed in the wrong direction.

Cause:
======
A previous commit [1] applied a specific `transform` to arrows to adjust their visual style,
By defining a new transformation for the snippet, the default generic transform for RTL language was overwritten.
https://github.com/odoo/odoo/blob/e0a5e68e861363378ecd184711bc9356fe0376ff/addons/web/static/lib/odoo_ui_icons/style.css#L105 Consequently, the arrows lost their RTL-specific orientation.

Solution:
=========
The CSS has been updated to explicitly handle the RTL context.

[1]: https://github.com/odoo/odoo/commit/d9ea6d1ebabf64dac434e0d2a7c2535bbfff5c71

opw-5440273

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

Forward-Port-Of: odoo/odoo#241541

*: pos_self_order, pos_online_payment_self_order

Two things will change with this PR.

First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one.
But now, it's not the case anymore. We only use it if, and only if, it is available in self.

The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. 

If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. 

If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`)  and put the product as `available in self` as well.

task-id: 5190541
enterprise pr:https://github.com/odoo/enterprise/pull/103063

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

Forward-Port-Of: odoo/odoo#234522

### Behavior:


#### Current:
During the assignment of a picking,
if several of its moves have the same origin,
it will repeat that origin in its own origin.

#### Expected:
Only have one time each origin.

### Steps to reproduce:

From Inventory
* Enable two step transfer for the warehouse

From Barcode
* create and validate new receipts with "Product A"
* create and validate a second new receipts with "Product A" and other products 

From Inventory/Operations/Transfers/Receipts
* Open the corresponding receipts
* In "source Document" (Field: origin, Model : stock.picking) we can see that the reference from second receipts is repeated.

### Observation:
In the case of already existing origins it will not duplicate them but it's missing if several item comes from the same origin. https://github.com/odoo/odoo/commit/0caa44ca97d9d197811a03ad2ff227df68d4437a#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR1410

opw-4970159

Forward-Port-Of: odoo/odoo#232579
Forward-Port-Of: odoo/odoo#223251

### Issue:

The QualityCheck component is defined in the `mrp_workorder` module:
https://github.com/odoo/enterprise/blob/7c64908258d5a0fb9adecd6dd2760e255e46314b/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L7
which is not a dependency (even indirectly) of the `quality_iot` module. Hence, if you install the `quality_iot` and enable debug mode, you will raise a JS [error](https://github.com/odoo/odoo/blob/a1583d0564552007a3d5f12d967c2c0036e05e44/addons/web/static/src/module_loader.js#L164-L169) because of missing dependencies:
> The following modules are needed by other modules but have not been defined, they may not be present in the correct asset bundle.

This happens because commit a13e38006d3cba6cab4565de2b014d294d2c0af3  added a patch of the QualityCheck component in the `quality_iot`
https://github.com/odoo/enterprise/blob/eda93203ec8da207768357ae91132a49881a2978/quality_iot/static/src/mrp_display/quality_check.js#L4
https://github.com/odoo/enterprise/blob/eda93203ec8da207768357ae91132a49881a2978/quality_iot/static/src/mrp_display/quality_check.js#L17

opw-5353986

Forward-Port-Of: odoo/enterprise#100899

### Issue:
Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description.

#### To reproduce:
1- Create a promotion called `AAA`:
  - Rules: If minimum 50.0 spent grant 1 point per order
  - Rewards: 10% discount per order in exchange of 1 point
 
2- Using debug mode, in promotion's reward view, change the `Description on order` to `AAA 10%`. Save the promotion and you can see the `Discount product`'s name is set to the same description.
3- Create another promotion called `BBB`:
  - Rules: If minimum 50.0 spent grant 1 point per order
  - Rewards: 10% discount per order in exchange of 1000 points.

4- In promotion reward's view change the `Discount product` to `AAA 10%` which is promotion `AAA`'s discount product.
5- Change the `Description on order` to `BBB 10%` and save.
6- You can see the name of `Discount product` is changed as well.
7- In promotion `AAA` and you can see the description and the name of `Discount product` mismatch.
8- Navigate to shop, and add a product to cart with a price of more than 50.
9. You can see after applying promotion `AAA` the description from promotion `BBB` is shown.

### Cause:
The technical field `Discount product` is never meant to be changed, and this field is introduced for reporting purposes and showing the discount applied in cart.

However, this field is added to view in #132857. This is done as a hack to find the `Discount product` created for the promotion, as a workaround for an accounting issue due to adding account to `Discount product`, and originally `discount_line_product_id` was not supposed to be shown or changed through form.

After discussion with PO, we decided this field should be removed from the view. Also removing this field will not undo the main fix of #132857, and that workaround was introduced only to find the `Discount product` for that specific client's use case.

However, in stable, it is kept for customization compatibility. It's set invisible in order to prevent the issue.

opw-5229633

Forward-Port-Of: odoo/odoo#240684