When changing `partner_id` on the `account.move.line`s of a duplicated journal entry if this journal entry already had a partner_id, it will stay the same (possible to see from list view) but the move line will be correctly changed.

Step to reproduce:

- Select a journal entry of type PBNK
- Duplicate the journal entry
- Change the partner on the journal items and save
- Go back to the list view, the partner name displayed is from the original journal entry

When clicking on duplicate it will call the function copy and super.copy() will call copy_data from account_move;

This line allow to copy the partner_id (which is needed since invoices revert goes through copy) Since there is no condition on the type of entry, it will also copy the partner_id in our case:
https://github.com/odoo/odoo/blob/22c333d0ed7eba1165f6462e668998d37fcabb73/addons/account/models/account_move.py#L2424-L2426

The introduction of this change introduced our issue, It allow for all duplication to copy the partner_id.
Original fix : https://github.com/odoo/odoo/commit/e1d18960b57b36b8bf69bc787ef6078dcba8c855

opw-4907648

Forward-Port-Of: odoo/odoo#223959
Forward-Port-Of: odoo/odoo#217755

### Steps to reproduce:
	- Go to any task in project module
	- Create a new meeting activity
	- Open Calendar and drag to create a slot
	- Notice the name of the meeting in the pop-up is the same as the task
	- Click on the expand button top-right of the dialog
	- Notice the calendar.event form opened but without a name

### Cause:
When expanding the view using 'More options' button we are keeping the context in the new request.

https://github.com/odoo/odoo/blob/d9c63a85955c2321bae1a705cc09b2554155f826/addons/calendar/static/src/views/attendee_calendar/attendee_calendar_controller.js#L45-L49

But when doing the same through the expand button we don't pass the current context so it will be lost.

https://github.com/odoo/odoo/blob/3dde420665257c63885e891f1ec366568df5007b/addons/web/static/src/views/view_dialogs/form_view_dialog.js#L106-L116

### Fix:
Backporting the commit https://github.com/odoo/odoo/commit/4f71fbbd26b428e57943d974e8441bef295cdef1
to pass the context while expanding the form view

opw-4966486

Forward-Port-Of: odoo/odoo#221422

Scenario:

- add a 2 columns content widget
- set the right column text to "On Scroll" animation with "Slide" effect
  and "From Right" direction so the content may be out of the page
- save and reload the page on mobile
- scroll down get in middle of animation with some content out of page
- try to scroll to the right

Result: we can scroll to the right and see the overflowing animated
content outside of the expected page limit.

History:

During an animation, a fix prevent the horizontal scrollbar by setting
"overflow-x: hidden" (or crop depending on version) on a given element:

- in odoo/design-themes@51abb093c77993363b170b12be134c95b3009895
  (14.0: 2021) it was added to $().getScrollingElement()
- in 189a7c96e6e26825dc05c0c6466576fe63aa091e (18.0: 2022) the main page
  scroll was moved from #wrapwrap to html
- in fece9cb85761e6cb3fe3642f947661464402363b (18.0: 2024) the
  "overflow-x: hidden" was moved to the body element

Cause: the "overflow-x: hidden" is ignored by mobile browser on html and
body tags ([example of report]), so in 18.0 and over the possible
horizontal scrollbar caused by an animation is not hidden.

Fix: apply the "overflow-x: clip/hidden" on #wrapwrap element.

[example of report]: https://stackoverflow.com/questions/14270084

opw-4575726

Forward-Port-Of: odoo/odoo#213802

**Steps to reproduce:**
- With pos_loyalty installed, launch the PoS
- Select a customer and make a purchase
- This needs to create a new loyalty coupon (new customer or program)
- The customer name is not displayed on the receipt

**Problem:**
When a customer is set for an order in pos_loyalty, it should appear on the receipt. Before this commit, sometimes it was not displayed.

**Why the fix:**
The customer was not displayed everytime because it was displayed inside this if statement, https://github.com/odoo/odoo/blob/033c7a63bdf3d10d9d2c5084959fd34f52011bea/addons/pos_loyalty/static/src/app/screens/receipt_screen/order_receipt/order_receipt.xml#L6 So the customer would only be displayed if there was a new coupon being created, and not if we were updating a new one. This behavior was introduced in a REF in 18.3 461359e The behavior does not make sense as it displays the customer for each new coupon we have in this order, so it might be displayed multiple times.
With this commit, we display the customer all the time, as it is weird to only display it if a new coupon is created or if loyalty logic is involved, as said here 879b415

opw-4929076
opw-4976885

As far as I can tell this can occur if the ws connection gets closed while we're in a `recv`: in that case `recv` will mark the connection as closed (`connected=False` and `sock=None`) and raise `WebSocketConnectionClosedException`, then any attempt to `send` will fail with `WebSocketConnectionClosedException`.

Here this likely is an issue because in `_receive` `WebSocketConnectionClosedException` goes through the generic exception handler, which sees that:

- it's not a `ConnectionResetError`
- the result is not set
- and the ws is not connected

So `_receive` just cancels the result and `return`s, and when whatever's waiting on a future finally times out it tries to cleanly shut down and hits a connection that's already closed.

Handle a connection closed in that context more properly:

- unset `ws` so we don't try to clean it up, as we know it's closed
- set the result as being in error
- cancel every future in order to immediately go to the tour failure step rather than wait for timeouts

Note that this will not really *fix* any error per se, because every time this happens it means the browser abruptly closed the WS connection (possibly straight up died), so this should mostly properly attribute the error so we can investigate it.

https://runbot.odoo.com/odoo/error/229793

Forward-Port-Of: odoo/odoo#224023

Currently, an error occurs when creating an expense for an employee that is not linked to a user.

**Steps to reproduce:**

- Install the `hr_expense` module.
- Create a new employee `test` (ensure this employee is not linked to a user).
- Go to Expenses > upload [1] and open it.
- Set the `Employee` to `test` and click `Save` (it may take up to 5 seconds).

(See [2] for Steps to reproduce)

**Error:**
`AttributeError: 'hr.expense' object has no attribute 'uid'`

**Root Cause:**
At [3], the code incorrectly uses `self.uid` instead of `self.env.uid`. Since `hr.expense` records do not have a `uid` field, this leads to an `error`.

**Fix:**
This commit ensures that expenses can be saved correctly, even when the selected employee is not linked to a user.

[1]:
https://drive.google.com/file/d/1Ew2B_zMFCQbw-6nwfKctJPy1W4y2ZaIb/view?usp=sharing

[2]:
https://drive.google.com/file/d/1qP-9L_emaox3l9JyoNVYjqj1Ht8bJSmZ/view?usp=sharing

[3]:
https://github.com/odoo/enterprise/blob/804f263b80cb78884e3f246bcc7fa7ea4e0cf73a/hr_expense_extract/models/hr_expense.py#L90

sentry-6834628909

An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted.

**Steps to Reproduce:**
1) Install Sales and Web Studio modules.
2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button.
>- Set Allowed Group to Access Rights.
>- Set Responsible User to Mitchell Admin.
3) In the Incognito Tab, login as Demo, open the same sale order and click on
   preview to create activity in chatter.
4) Delete the Approval Rule in the original tab.
5) Switch back to Demo and click Mark Done under Planned Activity in chatter.

**Error:**
`SyntaxError: syntax error at or near ')'`
 `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^`

**Root Cause:**
The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error.

[1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366

**Solution:**
This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty.

sentry-6306636466

Forward-Port-Of: odoo/enterprise#86982