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

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

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

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

Forward-Port-Of: odoo/enterprise#102859

A warning appears on the Employee profile if an active employee is missing from an open Pay Run.

**Before:**
- The system checks if the employee payslip is explicitly linked to the open Pay Run.
- If they are not linked, it raises a warning ("The pay run is missing this employee"), even if the employee already has an off-cycle payslip for that specific period.
- The system treats this as an issue and prompts the user to add the off-cycle payslip to the run.

**After:**
- The logic now also considers Off-Cycle payslips. If the employee has any
off-cycle payslip covering the pay-period dates, no warning is shown.
- An issue is shown only when the employee has no payslip at all for the period.

- When showing the issue:
If multiple pay runs exist for the period:
Display a single message: "The employee is not currently in any pay run." with an action to view available pay runs.

- If only one pay run exists for the period:
Display a contextual message: "The pay run [payrun name] is missing this employee." with an action "Add payslip to Pay Run".

- If the employee is present in any pay run or has an off-cycle payslip for the
period: No message is displayed.

Task-5387310

Before this commit, when the user starts another timer from another company, the existing timer should be stopped before starting a new one. However, if industry_fsm module is installed and the previous timer is running from another company, the user could have an Access Error because he cannot read the task/ticket linked to the timesheet with the timer to stop.

This commit makes sure the timer is correctly stopped without any issue even if the record linked is inside another company.

Steps to reproduce the issue:
============================
1. Install industry_fsm module
2. Create a task from a timesheetable project and start a timer from that new task.
3. Create a new company and go inside that company
4. Create a new timesheetable project and a new task inside it
5. Start a new timer from that new task.

Expected Behavior:
-----------------
The timer form the first task created should be stopped and a timer for the newest task should be running.

Actual Behavior:
---------------
An access error is raised because the user cannot access to the task linked to the timer to stop.

task-5076633

Forward-Port-Of: odoo/enterprise#102788
Forward-Port-Of: odoo/enterprise#96411

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

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#241951
Forward-Port-Of: odoo/odoo#239224

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

Before this commit, computing the `parent_id` of `account.move.line` records, involved looping over the `move_lines` grouped by their `move_id` sorted by the `sequence`. The updates on the move_lines are done per line and this involves an individual write operation on each one of them. The cardinality of the set of possible values of the new `parent_id` may involve a lot of values in cases where a big number of lines have a display type of either 'line_section' or 'line_subsection', in most of the cases it is not the case, so a possible performance improvement in the method is to upper bound the number of write operations by the cardinality of the set of possible values instead of a single write operation on each single `move_line`. This can be done by mapping the values to a record set of move lines and updating the move_lines that share the same value.

The benchmark below is done on an invoice that contained **2000** `move.line` records. An individual **write** operation is being done on each one of them.

| Scenario | Time (seconds) |
|-----------|----------------|
| **Before** | **Memory Error** |
| **After**  | **4s** |

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