Currently, when a user creates an activity with a note containing a file using `/file`, the attached file is not displayed in the chatter.

**Steps to produce:**
* Install `crm` with demo data
* crm > open any lead > Activity > use `/file` to attach  a file > Save

**Observed Behavior:**
The user cannot see attached files in the chatter.

**Root cause:**
* This behavior occurs because after commit [1], the `EmbeddedFilePlugin` started being used for all HTML fields with embedded components enabled, and since commit [2], all HTML fields have `embedded_component` set to true by default.

* As a result, file attachments may not display correctly, since embedded components do not render when HTML content is shown outside the editor.

**Solution:**
Disable the embedded component option for the note field in the activity to display the full HTML and make the attachment visible, instead of rendering-related data.

**Before:**
<img width="640" height="150" alt="image" src="https://github.com/user-attachments/assets/edabbe9f-eedf-4ef1-8f0d-749e0145ce8f" />
**After:**
<img width="651" height="148" alt="image" src="https://github.com/user-attachments/assets/8a3d1d3d-a5f8-4726-83be-6134e96db689" />

[1]:
https://github.com/odoo/odoo/pull/216572/commits/86c7176833fc36b9ca7d2989d31587c353bd5800 
[2]:
https://github.com/odoo/odoo/commit/a44b05fd06d8c157b5edacbd6a7061197eb4ee5f

opw-5426126,5361933

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

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

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

**Behavior:**
Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This causes issues for some users that want more specific formats like standard over extended, only arrivals/dispatches or both, etc... And this can cause them to not be able to submit their reports.

The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of.

**Steps to reproduce:**
- Connect to a company under Belgian Localisation.
- Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium)
- Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the  'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some  missing informations
- Create a Bill with the product with the same settings
- If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing.
- From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill.
- Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate

opw-5347238

Forward-Port-Of: odoo/enterprise#102531

* = hr_contract_salary

Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
  - Switch to the 'Salary Adjustments' tab.
  - Edit/save a record (tracking reads 'salary_offer_ids').
  - Click the 'Work Entries', 'History', or 'Offers' smart buttons.

Cause:
- HR Officers could still reach payroll-only data:
  - 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
     tracking reads on a model restricted to HR Managers/Recuriters.
  - The 'Salary Adjustments' tab and offer buttons remained visible even when
     the user lacked payroll rights.
  - The payroll overrides changed 'contract_date_start' to
    'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
    show AccessErrors while the buttons stayed visible.

Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
 'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
  HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
 'hr_payroll.group_hr_payroll_user' group when payroll is installed.

Task - 5188997

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