**Issue**
The lunch order merge logic was causing orders to be unexpectedly archived when they shouldn't be. Users would see their orders disappear from the list view after certain operations like clicking "Receive" multiple times or when trying to merge orders with existing ones in immutable states.

**Steps to Reproduce**
1st problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Select and click the "Receive" button again on the same order
- The order gets archived and disappears from the view

2nd problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Place another order for the same product as before
- From the order list view, once the second order is set to received, it gets archived and the update quantity logic not triggered

**Root Cause and Solution**
1st problem: When searching for matching orders to merge, the current order being processed could match itself, leading to self-deactivation. Fixed by adding matching_lines = matching_lines - line to exclude the current record from potential merge targets.

2nd problem: The merge logic was trying to combine new orders with existing "sent" and "confirmed" orders, but the update_quantity method correctly excludes these states since they shouldn't be modified once sent/received. This created a mismatch where orders would be archived but quantities wouldn't update. Fixed by excluding "sent" and "confirmed" states from merge target searches entirely.

Task ID: 5123211

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

Forward-Port-Of: odoo/odoo#229084

**PROBLEM**
When hiding a HtmlField field from a view with pending images in it, there is a traceback.

**STEP TO REPRODUCE**
1. Using studio, create a HtmlField on the view of your choice.
2. Add a checkbox next to it, and link the HtmlField visibility to the button.
3. Add a image to the HtmlField (don't save the record !)
4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image).

**CAUSE**
commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed.

**FIX**
We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)`

opw-5061820

Forward-Port-Of: odoo/odoo#227482

**Steps to reproduce:**
- Set your database in a language with a "," as a decimal separator, such as French
- Make a purchase, chose a payment method
- Before paying, click any +10/20/50 button
- The price will be multiplied by 100, then add the desired amount

**Why the fix:**
There were two places where the decimal separator was causing issues.

First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers.

Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number.

We now convert the numbers and the strings using the correct decimal separator.

opw-5126224

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

This PR addresses the following issues:

**Issue 1: Date Misalignment**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.

**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.

**Expected Behavior:**
The date should align with the blog post content and tags preview.

**Issue 2: Some Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.

**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler 
function, which extracts the URL from the `value` attribute of the `<option>` tag.


**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.

**Issue 3: All Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.

**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.

**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.

task-3937884

Forward-Port-Of: odoo/odoo#230313
Forward-Port-Of: odoo/odoo#225845

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#230166
Forward-Port-Of: odoo/odoo#221570

Recently pull request https://github.com/odoo/enterprise/pull/86084 introduced an ondelete method on `ir.model` that retrieves some worksheet templates to delete them.  However, this method breaks when uninstalling module `worksheet`:
```
ir.model.data._module_data_uninstall():
    ... records are deleted ...
    ir.model.fields.unlink():
        drop column of corresponding fields
        delete ir.model.field records
    ir.model.unlink():
        drop table of corresponding models
        ir.model._unlink_if_uninstalling():
            self.env['worksheet.template'].search([('model_id', ...)]).unlink()
        delete ir.model records
```
The call to `ir.model.unlink()` crashes when searching for worksheet templates, since column `model_id` has been dropped already.  This makes the transaction fail, and it is rolled back to a savepoint just before the call to `ir.model.unlink()`.  In other words, the uninstallation manages to drop most of the columns that must go, but fails to drop all the tables that must go.  And the uninstallation proceeds anyway...

Now consider uninstalling module `resource`.  That module defines model `resource.calendar` with required field `name`, and also defines a record in that model (a default calendar).  When the module is uninstalled, module `worksheet` is also uninstalled (because it depends on `resource`), and so the situation above happens.  Consequently, most of the columns of table `resource_calendar` are dropped, but the table is not.  If we reinstall module `resource` after that, the ORM re-creates column `name` (which is `NULL` on the default calendar at least), but fails to add the `NOT NULL` constraint on that column.

The fix consists in avoiding the `search()` above in the ondelete method if the column `model_id` does not exist anymore.

Forward-Port-Of: odoo/enterprise#96845

When coming back to a view using the breadcrumb or with the view switcher, we want to restore the local state of the view as it was when we left it, in particular the scroll position. This is handled by the `useSetupAction` hook, for all views (except for the list as the scrolling container is custom, because of the fixed table header).

However, since [1], it was no longer working in kanban, pivot and list (mobile only). This was due to the fact that those views are now "lazy", i.e. they are rendered directly, without the data, such that the control panel is available asap. As a consequence, when `onMounted` is called (i.e. when the hook attempts to restore the scroll position), there's no scrollable content yet.

This commit fixes the issue by allowing the controllers to restore the scroll position themselves, when their content is ready. In addition, a custom treatment was necessary for the kanban view, in mobile *and* if grouped, as each column has its own vertical scrollbar.

[1] https://github.com/odoo/odoo/pull/205129

task~5086324

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

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

**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.

**Additional fix**:
[This commit](https://github.com/odoo/odoo/commit/886b3ea5d463722413f3cae14d4be1ad5fc88ab9) changed the default of `to_refund` to `True`. Combined with [this change](https://github.com/odoo-dev/odoo/blob/1e7ffa60dc1495243d8d99ac03c1701fbd056fe1/addons/sale_stock/models/sale_order_line.py#L330C13-L330C94), returning a rental product is treated as an incoming move, which incorrectly decreases the delivered quantity. To fix this, rental products are never marked as refundable when the SO is created: we adapt the procurement value to set `to_refund=False` on rental return moves. This ensures the delivered quantity is correctly updated for rental products, while non-rental products in a rental context remain refundable.

opw-4894358

Forward-Port-Of: https://github.com/odoo/enterprise/pull/91825

Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and there is an “expected singleton” traceback in the logs. This is because in the method `_parse_form_data` in `l10n_co_website_sale`, the obligation type field on `form_data` is set to be a  list of “type ids” which leads to an error when `convert_to_cache` is called as the browse function in this attempts to convert the list to a tuple of single characters. For example, if the list is ["10"], it gets converted to ("1","0") hence leading to the expected singleton traceback.

Purpose: Instead of passing a form list to form_data,we pass the record set which will correctly set the values in the address, much like how `default_obligations_ids` is also currently set. After this correction, the website address screen will save the address properly and redirect to the delivery screen for further actions.

Steps to Reproduce on Runbot:
1. Create a Colombian company, make sure l10n_co is installed
2. Set the company on the website to this company
3. Ensure that there is a record in the table `l10n_co_edi_obligation_type_ids` with id > 9. Create one if it does not exist.
4. Open the /shop page in incognito mode as a public user.
5. Add a product, go to the checkout page, proceed to the address page.
6. Enter all the information including the Identification Number (e.g. 623.456.789-1). Choose “NIT” in identification type and select the type code from step 3 in the dropdown for obligation type. Choose country “Colombia” along with a state and city 
7. Click on "Continue checkout". The page gets stuck in a loading state
 forever.

opw-4776301

Forward-Port-Of: odoo/enterprise#90862