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

Scenario:

- install RTL language on website (eg. Arabic)
- go on mobile (eg. chrome developer tools and enable mobile) on website
- in arabic, go down to get the navbar that follow the top of viewport
- go up to the top

Result: there is a 200ms moment when all the interface is moved ~90% to
the right outside of the viewport.

Cause:

In RTL, the header has this state when going down in the page:

- the class: o_header_affixed
- the inline style "transform: translate(0px, -100%);"
- the transition
```
.o_header_affixed {
    position: fixed;
}
.o_header_affixed:not(.o_header_no_transition) {
    transition: transform 200ms;
}
```

When we go up, the o_header_affixed class is removed as well as the
inline style, but the transition causes 200ms during which we have a
transform without header having the "position: fixed".

This seems to be caused by that situation which makes the offcanvas menu
(mobile menu that appear when clicking on hamburger icon) be at
top:0/left:0 of viewport instead of being at top:0/left:-100%, this
cause all the content to be offset to the right.

Fix:

Force the transition stop if we are at the top of the page where the top
menu is shown and not the affixed menu.

opw-5173822

__PR NOTE:__

Note: I have not been able to reproduce in a small reproduction (such as jsfiddle) so I must be missing one element for the reproduction.

It is "easy" to reproduce and check what is happening when changing the animation to eg. 20000s in this line:

https://github.com/odoo/odoo/blob/d8a875dcdd1262d2d3f15ff9c414e605a7b54526/addons/website/static/src/scss/website.scss#L1493

Then you don't need to block the debugger in the 200ms to check DOM and so on.

The issue is happening in 18.0 but it has been reported in 19.0 and the code has changed between the two so I'm targeting saas-18.4 version.

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

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`.

[enterprise#99373](https://github.com/odoo/enterprise/pull/99373)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/odoo#235475

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#99373

Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070)
Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672)

---
## Error
FAILED: [12/46] Tour test_refund_does_not_decrease_points → Step selection popup has '$ 1 per point on your order' (trigger: .selection-item:contains("$ 1 per point on your order")).

## Qualifiers
{
	"module": "pos_loyalty",
	"test_path": "/pos_loyalty/tests/test_frontend.py",
	"tour_name": "test_refund_does_not_decrease_points",
	"tour_step": ".selection-item:contains(\"$ 1 per point on your order\")",
	"test_class": "TestUi",
	"test_method": "test_refund_does_not_decrease_points",
	"test_module": "pos_loyalty"
}

## Fix
In some cases, the POS config's `pricelist_id` was not available in the frontend, causing loyalty program conditions to be skipped when checking for a matching pricelist.

By explicitly setting `use_pricelist` to True on the POS config, we ensure that `config.pricelist_id` is properly loaded and available at runtime, allowing loyalty programs with pricelist conditions to behave as expected.

Forward-Port-Of: odoo/odoo#221921

Steps to reproduce:
1. Go to the theme tab and change the colors of the main preset.
2. Select any text in the footer.
3. Expand the toolbar and click the highlight option.

Issue:
The highlight selector still uses the default purple color instead of adapting to the updated theme preset. This happens because the text highlight color uses "--o-color-1", which does not update when the theme colors are modified.

Fix:
Used "var(--hb-cp-o-color-1)" as the default text highlight color instead of "--o-color-1", ensuring the highlight automatically adapts to theme changes.

Before This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="450" height="404" alt="image" src="https://github.com/user-attachments/assets/c92eed7e-1856-4e08-879a-a74e2506ab9c" /> | <img width="399" height="389" alt="image" src="https://github.com/user-attachments/assets/9a938e80-9e01-49fd-b6a1-cf9baaa64358" /> |


After This Fix:
| highlight selector color before changing theme preset | highlight selector color after changing theme preset |
|-----------------------------|---------------------------------|
| <img width="394" height="413" alt="image" src="https://github.com/user-attachments/assets/674958bc-7df7-44fa-97c0-5ae78608dc6a" /> | <img width="408" height="428" alt="image" src="https://github.com/user-attachments/assets/1d48ca49-7d18-4681-8443-b9887eef0dbf" /> |

task-5375414

Co-author: Alay Patel <alap@odoo.com>

**Description of the issue/feature this PR addresses:**
----------------------------------------------
In version 19, when a message in the Chatter includes an attachment and an emoji
reaction is added, both elements appear visually too close to each other.
This overlap creates a cluttered look and reduces readability in the message view.

**Current behavior before PR:**
----------------------------------------------
- Emoji reactions and attachment previews are rendered too close together.
- Negative or insufficient top margin on the reactions container causes overlap.
- Visual inconsistency between text-only messages and messages with attachments.

**Desired behavior after PR is merged:**
----------------------------------------------
- Proper spacing between attachments and emoji reactions in the Chatter.
- Consistent, clean layout across all message types.
- Improved readability without affecting compactness for text-only messages.

Task-5259482

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

Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#238977

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