Currently, the customer, who did not perform the operation, is set 
as the author of the refund, capture, and void transaction messages.

**Steps to reproduce:**
- Install the `sale_management` module and enable the `demo` payment provider.
- Create a new quotation and from the `gear` icon, select `Mark Quotation as Sent`.
- From the `gear` icon, choose `Generate a Payment Link`, and copy the link.
- Open the link in an incognito window, and complete the payment.
- Return to the original tab and open the payment transaction from the chatter.
- Click `Refund` > `Refund` and observe the `author` of the messages in the chatter.

**Observation:**
The refund messages entry shows the customer as the author instead of the 
logged-in user who executed the refund.

**Root Cause:**
At [1] and [2], when the logged-in user is not a superuser, the code assigns 
the customer (`self.partner_id`) as the author, even during `refund`, `capture`, 
and `void transactions`, resulting in an incorrect message author.

**Fix:**
This commit ensures that during refund, capture, and void transactions, 
the message author is set to the logged-in user instead of the customer.

[1]:
https://github.com/odoo/odoo/blob/bbf3bd7b0e1d3e015350f9c959fad056384e2318/addons/account_payment/models/payment_transaction.py#L223

[2]:
https://github.com/odoo/odoo/blob/5cf325dfff1ffbc1c4b4d0bcfc44ac9f55ea7c51/addons/sale/models/payment_transaction.py#L110

**Before:**
<img width="1910" height="624" alt="5379376_before" src="https://github.com/user-attachments/assets/decdd620-d741-488e-9dec-e5c8c9bafc48" />

**After:**
<img width="1917" height="622" alt="5379376_after" src="https://github.com/user-attachments/assets/5f38f3c3-fd2c-489e-afc9-d7a356fde23a" />

opw-5379376

Forward-Port-Of: odoo/odoo#241923
Forward-Port-Of: odoo/odoo#239224

Issue
-----
After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step.

Steps to reproduce
-----
- Enable multi step routes
- Set WH to 3-step manufacturing
- Create a product
	- empty bom
	- MTO & manufacturing routes
	- 5 in stock
- Create a SO for the product
- Cancel the linked MO
- Open the delivery picking
- Click "Check Availability"

> The product is not getting reserved from stock

> The delivery picking is still "Waiting Another Operation"

Cause
-----
The problem happens in `action_cancel`

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995

In 1-step case, `move.propagate_cancel` is false so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021

where `move_dest_ids` is the move of the delivery picking.

This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931

instead of going into the `else` part

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949

In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014

which lacks the swap to MTS and unlink `move_dest_id` logic.

Solution
-----
We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by

https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012

This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754

and since it was set to MTS, it goes into the `else`part of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216

-----
Ticket:
opw-5124380

Forward-Port-Of: odoo/odoo#241579
Forward-Port-Of: odoo/odoo#237890

Steps to reproduce:

- Create service product with UoM 'pack of 20 hours' and prepaid policy
- Sell the product and confirm the Sales Order
- Create a helpdesk ticket/task linked to the Sales Order Line
- Log 22:00 on timesheets

Current behavior:
Sales Order Line shows '-2:01 remaining'

Expected behavior:
Should show '-02:00' to reflect two hours overconsumed without rounding.

Root cause:
Python's float type follows the IEEE 754 double-precision standard,
where only base-2 fractions can be stored precisely. Base-10 fractions
cannot be represented exactly, introducing tiny rounding errors.  
During chained operations such as multiple conversions or subtractions,
these small errors accumulate into larger discrepancies.  
The float_round() function uses a small constant epsilon to correct
rounding noise, but as arithmetic chains grow, errors exceed epsilon's
tolerance and it can no longer correct them.  
Since a single global epsilon cannot handle every case (small vs. large
values, chained vs. single operations, or regressions), rounding drift
is inevitable when rounding happens repeatedly.

Fix:
To prevent these rounding errors from compounding, the solution is to
stop intermediate rounding altogether. By using conversions with
round=False, all arithmetic is done in the base unit (hours) with full
float precision, and rounding is applied only once when displaying the
final value. This eliminates error accumulation and ensures consistent,
drift-free results.

task-5090240

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

Forward-Port-Of: odoo/odoo#240403
Forward-Port-Of: odoo/odoo#229282

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

Forward-Port-Of: odoo/enterprise#95615
Forward-Port-Of: odoo/enterprise#87867

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later.

It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this
upgrade script: https://github.com/odoo/upgrade/pull/9153

1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it.
2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout`
3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12
4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore
5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie
6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1

Forward-Port-Of: odoo/odoo#241671
Forward-Port-Of: odoo/odoo#241129

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