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)

*: website_slides

This commit fixes the 'selected' display of the SelectMenu component in some frontend implementations. Previously, the visual style would be broken since the 'active' class was set on the element, having a blank text and background on selected items.

The right 'selected' class is now used, to avoid difficulties to read the value, while still having some frontend specific styles working as expected. Also, the form-control and form-select classes are set using the togglerClass props. In future versions, we might be able to remove extension of the component in other modules (e.g. hr_contract_salary), ensuring the same style and behaviors accross all places.

Before: 
<img width="1566" height="1115" alt="image" src="https://github.com/user-attachments/assets/6265c615-bd7a-47f6-9353-c503dd934fed" />

After: 
<img width="791" height="350" alt="image" src="https://github.com/user-attachments/assets/939b7109-a32f-4991-a169-13f501f29eb4" />

Forward-Port-Of: odoo/odoo#240576

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

In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable.

By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it.

We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`.

### Notes:
This issue only happened from time to time for the client, and it seems non deterministic. 
If we disable showing the product images, the issue stops happening.

The below before vs after screenshots are taken on MacBook Pro 14 inches.

### Before:
<img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" />

<img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" />


### After:
<img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" />

<img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" />


opw-5392359

Forward-Port-Of: odoo/odoo#241941
Forward-Port-Of: odoo/odoo#241731

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

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