**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/odoo#224714
Forward-Port-Of: odoo/odoo#222093

**[FIX] iap_extract: fix crash when clicking on another column of x2many**

When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling the values for a field and the user clicks on another column.

This happened because the `getNewRecordValues` function was using the current value of `this.activeBoxType` to get the value for the new record. This is incorrect as `this.activeBoxType` can change when the user clicks on another column of the x2many.

---

**[FIX] iap_extract: fix line matching in manual correction component**

In the logic that handles the matching of selected boxes with existing lines, it was assumed that the existing lines were sorted from top to bottom, but that wasn't guaranteed.
When it's not sorted, the out-of-order existing lines couldn't be match to the selected boxes.

---

**[FIX] iap_extract: fix loss of focus when clicking on image viewer**

When the attachment showed by the viewer is an image and the selected field is a date, a click on the image (to start a rectangular selection or to click a box) would cause a loss of focus on the field which caused the boxes to disappear, making it unusable.

This happened because the date fields are displaying a calendar popup which listens on the `pointerdown` event to hide itself when the click occurs outside of it. This causes the loss of focus of the field which hides the boxes.

On top of this, we also need to prevent the propagation of the click event when it occurs on the box layers, as it also causes the loss of focus on x2many fields (there is a global click event listener that exits the edit mode when the click occurs on another element).

These issues weren't noticed before as they only occur on image attachments. On PDFs, the viewer is embedded in an iframe that prevents the `pointerdown` and `click` events to be visible to the main document.

---

**[FIX] iap_extract: fix rectangular selection on scrollable images**

The rectangular selection needs to be adjusted when the user scrolls while selecting boxes. This was already properly handled for PDFs, but not for image attachments.

**Issue**:
Returning a non-rental product in a rental order does not correctly update the delivered quantity.

**Steps to reproduce**:
- Enable rental transfers via Settings > Rental.
- Create a rental order with (in that order!):
  - A rental product
  - A non-rental product
- Confirm the rental order.
- Open the related sale order.
- Go to the delivery and validate it.
- Return the delivery and validate the return.
- Observe that the delivered quantity in the sale order is incorrect.

**Cause**:
The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return.

**Solution**:
Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location.

opw-4894358

Forward-Port-Of: odoo/enterprise#93442
Forward-Port-Of: odoo/enterprise#91825

Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added.

Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers.

opw-4896074

Forward-Port-Of: odoo/odoo#230004
Forward-Port-Of: odoo/odoo#216737

Steps to Reproduce:

- Create a list in the editor.
- Apply a text color to an item.
- Change the font type of the text inside the list (e.g., to H1–H6).
- Apply a gradient color to text inside a list item.
- Move the cursor outside the list by pressing Enter twice and start typing in the new container.

Current behavior before PR:

- When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent.
- This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`.

Desired behavior after PR is merged:

- All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element.
- Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice.

task-5039499

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

Forward-Port-Of: odoo/odoo#231390
Forward-Port-Of: odoo/odoo#224262

Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product.

> Setup of the Loyalty Program (Discount & Loyalty):
Program Type : Loyalty Card
Rule : minimum 5 items => 10 Loyalty Points per $
Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points

Steps to reproduce:
-------------------
* Open the pos Shop
* Select a customer with loyalty points
* Add a Simple Pen
* Click on * Reward > Free Product - Loyalty Program

> Observation:
Customer shouldn't 'win' points here
New Total is mathematically correct but not logic

Why the fix:
------------
We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points.

opw-4914774

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

Forward-Port-Of: odoo/odoo#231056
Forward-Port-Of: odoo/odoo#221570

*: pos_online_payment_self_order

Before this commit:
===============
- When paying with a QR code, the screen kept showing the QR code even after
the payment was completed.
- Closing the QR popup manually and performing another action resulted in
a `Finalize order` error.
- This happened because the WebSocket handler flow were not updating
the order state properly.

After this commit:
===============
- Ensure the frontend refreshes payment status directly from the server
when the current order is updated.
- Remove unnecessary synchronization calls to prevent stale state.
- The order is now correctly marked as paid, and no finalize error occurs
after closing the QR popup.

Issue:
===============
- The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION`
was fetching the full `pos.order` unnecessarily, because the order state is
already updated by another WebSocket flow.
- `notify_synchronisation` in the self order flow was redundant, as updates
are already handled in the `pos_self_order` module’s `pos.order` file.

Task - 5107009

Forward-Port-Of: odoo/odoo#231444
Forward-Port-Of: odoo/odoo#229847

****Behavior:****

**Current:**
When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view.
- If the selected timesheets come from only a single private project : an Access Error is raised
- If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised

The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error.

**Expected:**
Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell.

So now when printing or exporting a timesheet from a single private project, no Access Error is raised.

**Steps to reproduce:**
- Create 2 different projects
- Create a task in each
- Assign it to another user (Make sure the other user only has user access to timesheets and projects)
- Set each project's visibility setting to private
- Log in with the other user
- Go to Timesheets --> List View

Single projects:
- Select one or multiple timesheet entries from one of the private projects
- Select Print -> Timesheets
- You should see an Access Error 

Multiple projects:
- Select one or multiple timesheet entries from a combination of both private projects
- Select Print -> Timesheets
- You should not have any Errors

opw-5127526

Forward-Port-Of: odoo/odoo#231188