**Steps to produce:**
- Install project module.
- Go to project > Open any project > Open any task > Click on gear icon.
- Click on Add properies > Set Field type as `Many2one` and Model as `Contact`.
- Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`.

**Issue:**
- The assigned value disappears after saving.

**Root cause:**
- At [1], since `id` is not an active field (see [2]), it is not present in
  record.data, which is expected. However, record.data is then passed to
  m2oTupleFromData, which assumes that the data includes an id because it is
  normally used on data coming directly from the ORM.
- Additionally, since display_name is also not present, m2oTupleFromData falls
  back to record.data.name, which is not proper.

**Solution:**
- Use an ORM read to retrieve the proper display_name of the record before
  constructing the Many2one tuple.

[1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89
[2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795


Before:
<img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" />

After:
<img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" />


**opw-5257819**



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

Forward-Port-Of: odoo/odoo#240443
Forward-Port-Of: odoo/odoo#238052

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

Steps to reproduce:
===================
- Install an RTL language (e.g., Arabic) on the website.
- Go to website & Edit mode
- Drop product snippet `s_dynamic_snippet_products`.

->When the website is viewed in an RTL language, the navigation arrows
in the snippet are displayed in the wrong direction.

Cause:
======
A previous commit [1] applied a specific `transform` to arrows to adjust their visual style,
By defining a new transformation for the snippet, the default generic transform for RTL language was overwritten.
https://github.com/odoo/odoo/blob/e0a5e68e861363378ecd184711bc9356fe0376ff/addons/web/static/lib/odoo_ui_icons/style.css#L105 Consequently, the arrows lost their RTL-specific orientation.

Solution:
=========
The CSS has been updated to explicitly handle the RTL context.

[1]: https://github.com/odoo/odoo/commit/d9ea6d1ebabf64dac434e0d2a7c2535bbfff5c71

opw-5440273

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

Forward-Port-Of: odoo/odoo#241541

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

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

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

Steps to reproduce:

- Create service product with UoM 'pack of 20 hours' and prepaid policy
- Sell the product and confirm the Sales Order
- Create a helpdesk ticket/task linked to the Sales Order Line
- Log 22:00 on timesheets

Current behavior:
Sales Order Line shows '-2:01 remaining'

Expected behavior:
Should show '-02:00' to reflect two hours overconsumed without rounding.

Root cause:
Python's float type follows the IEEE 754 double-precision standard,
where only base-2 fractions can be stored precisely. Base-10 fractions
cannot be represented exactly, introducing tiny rounding errors.  
During chained operations such as multiple conversions or subtractions,
these small errors accumulate into larger discrepancies.  
The float_round() function uses a small constant epsilon to correct
rounding noise, but as arithmetic chains grow, errors exceed epsilon's
tolerance and it can no longer correct them.  
Since a single global epsilon cannot handle every case (small vs. large
values, chained vs. single operations, or regressions), rounding drift
is inevitable when rounding happens repeatedly.

Fix:
To prevent these rounding errors from compounding, the solution is to
stop intermediate rounding altogether. By using conversions with
round=False, all arithmetic is done in the base unit (hours) with full
float precision, and rounding is applied only once when displaying the
final value. This eliminates error accumulation and ensures consistent,
drift-free results.

task-5090240

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

Forward-Port-Of: odoo/odoo#240403
Forward-Port-Of: odoo/odoo#229282

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

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

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

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

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

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

[FIX] mail: avoid error on service worker push subscription change

Sometimes, the `pushsubscriptionchange` event is called without an
`oldSubscription` defined, which can lead to an error occurring inside
the  service worker.

Steps to reproduce:

1. Enable notification in Odoo.
2. Reset the permission in the Chrome interface
3. Re-enable the permission inside the discuss systray by clicking on
the Odoobot message.
=> The pushsubscriptionchange is called without an oldSubscription


[FIX] mail: ir_cron_web_push_notification are now more robust

With a user having 5 registered devices for push notifications
if a browser registers with an endpoint that has a wrong domain
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX
the cron job cannot resolve the invalid domain of the endpoint and ends
up disabling it.


[FIX] mail: push_to_end_point method to support .invalid TLD

if a browser registers with an endpoint that has a TLD `.invalid`
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX

The TLD `.invalid`[1] is intended for use in online construction of
domain names that are sure to be invalid and which it is obvious at a
glance are invalid. The cron job cannot resolve the invalid domain of
the endpoint and ends up disabling it.

So we need to unregister a device with an endpoint with a `.invalid`
TLD.

[1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2


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

### Steps to reproduce:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**