**Issue**
The package of the selected quant is not proposed as a destination package when adding stock move lines manually before the move line is saved.

**Steps to reproduce**
- Activate 'Packages' in the settings
- Create a tracked product with package
- Put 10 units in stock in package `P`.
- Create and confirm a sale for 5 units
- Open the delivery, make sure the quantity is set to 0
- Click 'Details'
- "Add a line" and select the package P
-> if you try to select a destination package, the package P is not proposed as it should
- save it and reopen 'Details' 
-> if you try to select a destination package, the package P is now proposed

**Cause**
The domain of `result_package_id` (destination package) correctly includes `package_id`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L52-L56

However, before saving, `package_id` is not yet populated into the new `stock.move.line` record. It will only be copied from `quant_id` by `_copy_quant_info()`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L1016-L1025 which will only be called in the create method, while saving: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L350

opw-6370159

Steps to reproduce:
- set the "Product Price" decimal precision to 3
- create two products with a price of 42.609 and a 15% excluded tax
- create an automatic promotion granting a 20.4% discount on these specific products
- in the PoS, sell both products: the reward line shows -20.00 and the order total 78.00
- pay 100.00 in cash and validate

The synced order total becomes 78.01 while the customer paid 78.00.

The discount reward line is created in the frontend with an unrounded price unit: -(85.22 * 20.4%) = -17.384879999999995. The frontend computes taxes on the price unit rounded to the "Product Price" precision (see `get_unit_price()`): -17.385 -> -17.39 - 2.61 = -20.00 tax included, hence the 78.00 total displayed and paid.

However, the raw value is what is sent to the server and stored as-is (`pos.order.line.price_unit` is declared with `digits=0`). Whenever the backend recomputes the amounts from the lines - e.g. when a cash change makes `_process_payment_lines()` call `_compute_prices()` - the taxes are computed on the raw value: -17.38 - 2.61 = -19.99, and the order total drifts to 78.01.

Round the reward line price unit to the "Product Price" precision when creating it, as `_getRewardLineValuesProduct()` already does, so the stored value is the one the frontend computed its totals with.

opw-6322031

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

Forward-Port-Of: odoo/odoo#278383
Forward-Port-Of: odoo/odoo#275961

Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed.

This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'.

**Steps to reproduce:**
- Install the stock module.
- Open the Transfers list view.
- Add custom group for 'Printed'.
- Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'.
- Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu.
- Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view.

**Expected behavior:**
A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu.
close #235129

### Issue:
When a `stock.move.line` is manually added to a component move of a Manufacturing Order via the debug View button, it is not linked to the MO

This causes the line to appear without a `production_id` in Move History (shown in gray in 18.3+ instead of colored)

### Cause:
`production_id` is set on move lines in `_action_assign`, overridden in `mrp` to propagate MO-specific data: https://github.com/odoo/odoo/blob/e8d4ea2dc71109e9afc5b894c9359bcfc08295ae/addons/mrp/models/stock_move.py#L352-L358

In the normal flow, `_action_assign` is called by `_action_confirm` on the `stock.move`:
https://github.com/odoo/odoo/blob/737e28b9c8609d488d93ce7ce05941ff93779e04/addons/stock/models/stock_move.py#L1644-L1646

But when a line is added manually, the move is already created with state `assigned`, so `_action_confirm` skips the call and `_action_assign` is never executed

### Fix:
Setting `production_id` in `_action_assign` was incorrectly placed — there is no reason to set it during move assignment
Moving it to the move line creation avoids the issue entirely and removes the dependency on a code path that may not be triggered

### Steps to reproduce:
- Install `mrp`
- Create a BoM for a tracked product with 2 tracked components
- Enable Developer mode
- Create a Manufacturing Order for the product
- Unhide the View button on a component move and click it
- Add a new line for the first component (qty: 1)
- Confirm and Produce All the MO
- Go to Inventory > Reporting > Move History
- Add `production_id` via Studio (or check line color in 18.3+)

Before the fix, the manually added line has no `production_id` (and in 18.3+ the line is gray instead of colored)

opw-6250911

### 1. Prevent tour failure by waiting on the correct loading class

Before this PR, the tour introduced in commit [1] and modified in commit [2] could fail non-deterministically because it waited for `o_we_ui_loading` to disappear. However, this class was added with a delay in `operation.js`, allowing the next tour step to run before the loader was shown.

After this commit, the tour waits for `o_loading_screen`, which is added immediately and remains visible until the operation finishes. This ensures that the tour waits correctly before proceeding.

[1]: https://github.com/odoo/odoo/commit/091b8dee407fe30a115d4bb2e96d4d
[2]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711

**runbot:** [941508](https://runbot.odoo.com/odoo/error/941508)

---

### 2. Prevent tour failure by clicking the "Close" button instead of pressing "Escape"

Before this PR, the tour step introduced in commit [1], which pressed the <kbd>Escape</kbd> key to close the Insert Snippet dialog, could fail non-deterministically with the error:

> It is not allowed to do action on an element that's below a modal.

After this PR, instead of pressing <kbd>Escape</kbd>, the tour clicks the **Close** (`X`) button to close the dialog. This is a more reliable way to close the dialog and prevents the non-deterministic failure of the sync color shape tour.

[1]: https://github.com/odoo/odoo/commit/544a03775119021442d66486c24711d

**runbot:** [944543](https://runbot.odoo.com/odoo/error/944543)

Forward-Port-Of: odoo/odoo#278743

**Issue**
The height is not correctly computed in the picking form when editing product description.

**Steps to reproduce**
- Create a delivery for a product
- Add a description to it
- Click on editing the description
 -> Observe that the description is partially hidden because the widget height is incorrectly computed

**Cause**
Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root.

The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`:
https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 
**Solution**
Explicitly add a div around the product display and description to still use the `Autoresize`

Steps to reproduce the bug:
- Install point_of_sale
- Open the POS frontend and create a new product from the register
- Add it to the order, then open its product info popup and edit it
    - Rename it and change its price
- Confirm the edit dialog
- Click on the (renamed) product again to add it to the order

Problem:
On runbot the tour test_product_create_update_from_frontend (point_of_sale/tests/test_frontend.py, MobileTestUi) intermittently times out waiting for the orderline to show the edited product name/quantity/ price combination.

editProduct()'s onSave callback in pos_store.js closed the edit dialog via act_window_close right after firing this.data.read("product.template", ...) and this.data.searchRead("product.product", ...), without waiting for either call to resolve. When the dialog closes before those RPCs land, the in-memory product record used by canBeMergedWith() (pos_order_line.js) to decide how to merge/create the next orderline can still hold the stale price, so re-clicking the product right after editing produces an orderline that never matches the expected quantity/price.

Solution:
Make onSave async and await both this.data.read() and this.data.searchRead() before closing the dialog, so the reactive store is guaranteed to hold the updated product data before the user (or the tour) can interact with the product again.

runbot-223630

Forward-Port-Of: odoo/odoo#277698

**Description of the issue/feature this PR addresses:**

When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field.

This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list.

This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected.

**Steps to reproduce:**

- Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit
- In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode
- In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field

**Current behavior before PR:**

- Custom fields do not trigger inline edit mode

**Desired behavior after PR is merged:**

- Custom fields trigger inline edit mode

opw-6378102

Forward-Port-Of: odoo/enterprise#125239