Current behavior
When a customer emails an internal user and that email is forwarded to the helpdesk alias, the created ticket is linked to the internal user instead of the customer.

Expected behavior
When a ticket is created from an email sent to the helpdesk alias: 
-If the email is a forward, the ticket partner is set to the sender of the forwarded email. -If the email is not a forward, the ticket partner is set to the direct sender of the email.

Implementation
- Added detection of forwarded emails in `_message_parse_extract_payload` in  `mail.thread.py`. When found, the forwarded email sender is stored in `forwarded_sender`.
- Updated `message_new` in `helpdesk_ticket.py`. If `forwarded_sender` is present, set `email_from`, `partner_name`, and `partner_email` accordingly.
- Reset `partner_id` to `False` to allow correct partner matching.

Limitations / Notes
- RFC 2822 (`email protocol`) does not define a header that explicitly marks forwarded emails.
- Forward detection is heuristic and based on the presence of `From:`, `To:`, and `Subject:` headers in the email payload.
- This approach is error-prone if those headers appear for other reasons.
- Some mail providers translate these headers based on language settings, making detection impossible.
- Tested with Gmail and Outlook; other mail clients may behave differently and could cause incorrect ticket assignment or parsing errors.

Task [5138873](https://www.odoo.com/odoo/project/4105/tasks/5138873)

Steps to reproduce:
=======
1. Go to /shop in edit mode.
2. Change the Product Design.
3. Switch to the "Blocks" tab (so the "Style" tab is not visible).
4. Click on "Save".

Before this commit:
======
The selected Product Design was not saved.

After this commit:
======
The Product Design is now always saved correctly, even if the `ProductsDesignPanel` component has been unmounted.

Technical reason:
=======
The save behavior depended on whether the
`ProductsDesignPanel` component was still mounted at the moment of saving. If it was not alive, changes were lost.

Solution:
=====
We no longer depend on the component being alive. When the Product Design or the Gap is modified, we mark the product list with the `o_dirty_product_design_list` class. On save, we look for elements with this class, retrieve their modified data, and apply the changes.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#238851

When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions.

### Steps
1. Create a new Company with country Uruguay
2. Change current logged company to new Company
3. Change the currency to USD
4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank
5. Click manual synchronization
6. Check rates  

### Current behavior before PR

All currencies except UYU currency has created taxes with date today.
Only one error in UYU currency that is created with yesterday rate
![image](https://github.com/user-attachments/assets/adfdf9a1-f0cf-4825-bfe4-47ff5c8da2c4)

### Desired behavior after PR is merged:

All the currencies are created with the same date, the correct day that is today rate.

References: LATAM 1341 / ADHOC Task 51716

Forward-Port-Of: odoo/enterprise#85065

### Context:
In the Manufacturing app, users can create Manufacturing Orders to
create multiple products while assigning a unique serial number to each.
Users can either generate a list of serial numbers starting from a
first serial number, or provide a list of serial numbers themselves.

### Issue:
When providing a list of serial numbers without modifying the first
serial number field (`mrp.production.serials.lot_name`), the inputted
list is not used. Instead, another list starting with the unmodified
`lot_name` is generated and used.

### Cause:
In the `MrpProductionSerials.action_apply` method, the serial numbers
are updated if the first serial number field (`self.lot_name` in the
following code snippet) is left unchanged. This behavior overwrites
the list of serial numbers provided by the user.

https://github.com/odoo/odoo/blob/ac6960dc553088894e688bcc0f4a49245aa02d6c/addons/mrp/wizard/mrp_production_serial_numbers.py#L63-L67

### Steps to reproduce:
1. Install *Manufacturing* (`mrp`)
2. In Settings > Inventory, toggle *Lots & Serial Numbers*
3. Create a product tracked *By Unique Serial Number*
4. Create a Bill of Materials for the product
    - The BoM is required but its content is not relevant.
    Adding a single component with a quantity of one is enough.
5. Update the quantity of the component to be able to produce two products.
6. In *Manufacturing*, create a new *Manufacturing Order*.
    - Select the product and set the quantity to 2, then *Confirm*
7. Click *Generate Serial* or *Produce All*
8. **Do not** modify the *First SN* field, but write two serial numbers
(one per line) in the field below, then click *Apply*.
9. Click the *Serial Numbers (2)* smart button. The serial numbers we
used in step 8 were overwritten by the default *First SN* and its following SN.

### Solution:
This commit addresses the second bug described in https://github.com/odoo/odoo/commit/20158a115ef3dfb9fe2dd5103d3bed7e87e37940 without ever renaming
the serial numbers used for the MO. Now, the `product_id.next_serial`
matches a serial number from the list of provided/generated serial numbers.
The list of serial numbers is sorted to correctly handle cases such as:
```
First SN (self.lot_name) = '0000001'
self.serial_numbers = ['0000003', '0000002', '0000001']
```
In this scenario, we expect the *First SN* of the next MO to start at '0000004'.

The `else` clause of the condition was removed, as it would only be executed
if the `stock.sequence_production_lots` were removed. In that case,
`next_by_code('stock.lot.serial')` would return `False`, preventing
`lot_name` (or `next_serial`) from being updated correctly.

### Reason for second commit

The issue fixed by the first commit was replicated by https://github.com/odoo/odoo/commit/2548fd8d7f3b53a62089ac9122bd17524500ea1a in the subcontracting module (`mrp_subcontracting`). 
The first commit fixes the issue in the Manufacturing app (`mrp`), while the second commit fixes the issue in the subcontracting module (`mrp_subcontracting`). The fix and the test are similar in both commits.

opw-5373745

Forward-Port-Of: odoo/odoo#238678

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

**Description of the issue this PR addresses:**
Clicking on join call does not open the corresponding thread, 
neither in the discuss app nor in the chat window.

**Steps to Reproduce:**
- Log in with Admin and Demo user
- From the Demo side, open the chat window/discuss app and call Mitchell Admin
- On the Admin Side, click Join the call from the call invitation preview
- Chatwindow/Discuss app does not open the corresponding thread automatically

Additionally, clicking on the `invitation avatar` does not focuses the composer as 
expected in the chat window.

**Desired behavior after PR is merged:**
- Clicking join call now opens the corresponding thread in both discuss and 
chat window, with the composer focused in the `chat window`.
- Clicking the avatar on a call invitation now focuses the composer when opened 
inside a chat window.

task-[5367781](https://www.odoo.com/odoo/project/1519/tasks/5367781)

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

Forward-Port-Of: odoo/odoo#241919
Forward-Port-Of: odoo/odoo#239450

Steps to reproduce:
- Open the VoIP softphone on a mobile device
- Enter a number
- Place the cursor in the middle of the number
- Tap on the *odoo* backspace button
=> The character before the cursor is removed but then the cursor jumps
   to the end of the input.

Note: this also happens when trying to add a number in the middle of
the typed number, using the softphone buttons, but this message focuses
the explanation on the backspace button.

Commit [1] introduced the bug while revamping VoIP and its keypad.
Before that commit, there was a simple `t-on-click` defined on that
backspace button. After the update, that `t-on-click` is still there but
alongside a weird `t-on-touchend.prevent="(ev) => ev.target.click()"`,
which is actually there to prevent zoom-in behavior on double-tap,
although, retesting it does not seem necessary (at least on Android).
In any case, this is the original cause of the bug.
Since [2], the keypad input is using the mail's `useSelection` hook,
which, among other things, manages what happens on click outside of the
input. Before [1], this happened when clicking on the backspace button:

1. The click is handled during its *capture* phase by the `useSelection`
   hook. It checks if clicked location should be considered, the answer
   is yes.

2. The next part of the handler is done in the next microtask (as the
   check is done asynchronously (?? that looks like a bad idea, but
   that's another issue)).

3. That "in the next microtask" part occurs before the event starts
   bubbling: the capture handler saves the cursor position as being at
   the end of the input (?? not sure why, but that's another issue).

4. The click is handled during its *bubbling* phase by the backspace
   button's `t-on-click`, which removes the character before the cursor,
   and sets the cursor position accordingly for the `useSelection` hook.
   The actual cursor position is untouched since [3] on mobile "because
   otherwise it would open the mobile keyboard", but there are other
   ways that would have prevented that I think... to confirm later for
   master via task-5366961 (this actually causes issues in HOOT tests
   but that's another issue).

5. The dialer/numpad component handles the input's focus/cursor. For
   that, it forces a focus and ask the `useSelection` hook to "restore
   the selection", which "restores" it to what step (4) asked.

After [1], this changed to:

1'. Same as step (1)

2'. Same as step (2)

3'. As the click was simulated instead of being the "natural" one
    triggered by the browser touchend handling, the `t-on-click` handler
    is called now, before the "in the next microtask" part of the
    capture handler is done. That means what step (4) did happens now.

4'. Now what step (3) did happens now.

5'. Same as step (5)... but since step (3) and (4) were basically
    swapped, the cursor is now restored as the way it was last saved:
    at the end of the input (again don't know why step the
    `useSelection` hook would want to save it like that though).

There are multiple solutions to fix this:
A. Remove the `t-on-touchend` handler, letting the browser do what it
   naturally does. Although, it might be needed to prevent the mentioned
   zoom behaviors on some phones?
B. Review why the `useSelection` hook wants to save the cursor at the
   end of the input on external click, the point is valid but I am not
   sure that should be this hook's job to enforce it.
C. Review why the `useSelection` hook wants to check if the click has to
   be considered asynchronously, there should be a better way.
D. Configure the `useSelection` hook to consider a click on the
   backspace button as to be ignored, as handled manually by its own
   handlers anyway.

Option (A) should probably be done, by confirming zoom behaviors can be
prevented another way, but it cannot be done in stable anyway. The (B)
and (C) options should be investigated but would also not be stable to
change; also that would modify an exposed hook's behavior so more risky.
Option (D) can probably be done either way and is targeted on fixing the
bug described only, so this is the solution this commit went for.
In master, option (A) will be investigated in the forward-ported version
of this fix.

However... the bug was actually solved 3 months after [1], at [4] thanks
to secret option (E): not removing the `t-on-touchend` but changing it
entirely to call the same handler as the `t-on-click` one. A bit more
stable than option (A) but still not stable.
However... that solution (E) was broken 1 month later, again, by commit
[5] which destroyed step (5) while fixing an unrelated bug. Without that
step, the input cursor is not repositioned after OWL changes the value,
and by default OWL places it back at the end.

The solution is to restore step (5): the problem was that we were
checking if the user was not typing in another input before re-focusing
the keypad input... but the code considered the keypad input itself as
"another input". This commit still adds solution (D) on top of fixing
that, for good measures.

Note that in 19.0+, there is at least another cursor-related bugs,
related to commit [6]. It will be fixed in the forward-port of this one
as they need each other's fix to both work. Really there should be
better ways to handle that cursor position in OWL... might be done in a
future refactoring.

This commit adds a test to hopefully keep the bug fixed, as inspired by
commit [7].

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[2]: https://github.com/odoo/enterprise/commit/2e8f18801156a8069e26fb3d61d4f8d84893e891
[3]: https://github.com/odoo/odoo/commit/adc5448adf863b99b9b2be29985e560f5c12dbd4
[4]: https://github.com/odoo/enterprise/commit/668467678312632b5b9ecf234280690151bf3078
[5]: https://github.com/odoo/enterprise/commit/db82135fd73d5077fc26be7206105192a845c2bc
[6]: https://github.com/odoo/enterprise/commit/a06c02e8e163ed052c1c4d25a56bea9b6409abde
[7]: https://github.com/odoo/enterprise/commit/613ef7332b0d21e947871e9d33b68d069f1412c2

Related to task-5366961

Forward-Port-Of: odoo/enterprise#102825
Forward-Port-Of: odoo/enterprise#101856

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

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