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

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

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

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

Versions
--------
- 17.0+

Steps
-----
1. Have a coupon program;
2. add a 10% discount on order reward for 1 point;
3. add a 50% discount on order reward for 5 points;
4. generate a coupon with 10 points;
5. use coupon code on a confirmed order;
6. select 10% discount reward;
7. change to a 50% discount reward;
8. check coupon point total.

Issue
-----
Even though the 5 point reward was used, only 4 out of 10 points remain.

Cause
-----
When updating the reward line of a confirmed order, it keeps track of point cost changes before & after a write. Its purpose is to restore back the point difference on the coupon record.

The issue is that while point changes are stored, coupon changes are not. When updating reward lines, `_reset_loyalty` is used, which removes the `coupon_id` from the lines. As a consequence, attempting to restore the point difference on `line.coupon_id` after an update, it writes to an empty record.

Solution
--------
Store both coupons & their used points before write. After write, restore the previous points to the previous coupon, and subtract the current point cost from the current coupon.

This way, any combination of coupon/point changes should have the points updated as expected.

opw-4910922

Forward-Port-Of: odoo/odoo#230907
Forward-Port-Of: odoo/odoo#222054

### Steps to reproduce:

- In the settings enable: "Batch, Wave & Cluster Transfers"
- Create 2 deliveries
- Barcode > operations > Delivery orders > Batches > New
- Add your two deliveries and confirm
- Scan WH-Stock
#### > The scan fails considering you scanned each letter independently.

### Cause of the issue:

When the barcode is scanned a call of the split barcode will be launched to split the barcode in multiple barcodes according to the `barcode_separator_regex` present in the config:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_model.js#L613-L632 The issue lies in the fact that even thought the is `barcode_separator_regex` was conrrectly populated at the onWillStart of the mainComponent:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L97 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_picking_model.js#L36-L38 It was reset by the batch confirmation here:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L123-L135 because this part of the config is not meant to be returned by the private method `_get_barcode_data` but rather by public complete version `get_barcode_data`:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L91-L98 Now, since no `barcode_separator_regex` was provided to our new config, each character will be considered to be considered as an independent barcodes and the `WH-Stock` barcode will not match any location.

opw-5062331

Forward-Port-Of: odoo/enterprise#95295
Forward-Port-Of: odoo/enterprise#94056

This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry
(`account.analytic.line`) creation, and the duration field is created using the company schedule.
The reason is the case which the employee schedule starts before company scheudle or ends after it.

To reproduce the bug:
1- Make a db with fr company (install l10n_fr)
2- Make two working schedule:
- Company schedule with working day on Monday from 8:00-12:00 13:00-17:00
- Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15

3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee
4- Allocate some time off to the employee and take a time off on Monday
5- Check the work entries for the day you took the day off on timesheet app
6- 7:24 `Worked Hour` is shown instead of 7:40

The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered.

opw-4868643

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

Forward-Port-Of: odoo/odoo#230621
Forward-Port-Of: odoo/odoo#222262

This commit reverts [1], [2], [3], and [4]. (It actually results in
minimal changes since those commits were already removing parts of
each other.)

Issue before those commits:
1. Setup a auto-fifo category and two storable products (a component
   and a finished product)
2. Receive one compo at 10, then one at 25
3. Produce two MO with one finished product
4. Unbuild the second one

Error:
- For the component, we just use the value of the consumed
  components: IN 1 @ 25
- For the finished product, we process it as a classic out. Reminder,
  we are in FIFO: OUT 1 @ 10

As a result, thanks to the unbuild, we have created
- A over-valuation of the stock (+15)
- An outstanding balance of the "Cost of Production"

This is why [1] has been merged. However, it brought some other
issues, cf [2], [3] and [4]. Unfortunately, it still has some issues
- After the above use case, the difference between the debit and the
  credit of the stock valuation account is no longer the sum of the
  remaining values of the layers
- Adding some landed costs on MOs will lead to a traceback when
  undbuilding
- The over-valuation of the stock (that was already present before [1],
  cf above) is still present

Following some discussions with R&D and the product owners, we have
decided to start over from scratch, which means:
- Revert all commits
- Try another approach (if so, the new PR will be linked to the PR
  related with this commit)

[2], [3], and [4] are partially reverted: the tests can remain, as
they were only failing due to a sequence of changes.

[1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3
[2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c
[3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47
[4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0

OPW-5036574

Forward-Port-Of: odoo/odoo#226380
Forward-Port-Of: odoo/odoo#225728

Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change.

Steps to reproduce:
-------------------
* Install l10n_es_pos, switch to es company
* In the config of a shop, use fiscal position, set some as available, one as default
* Open shop session
* Add a product that has taxes
* Switch fiscal position to one that has 0% taxes
* There should not be taxes in the cart at this point
* Go to pay the order (cash or bank)
> Observation: On the receipt the previous tax value is counted as
  change

Why the fix:
------------
The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929

The fiscal position is updated with the partner's fiscal position or the default one if none on the partner.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995

Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp.

opw-5051231

Forward-Port-Of: odoo/odoo#229237

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

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

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.

Step to reproduce:
- Start database without demo data and install Subscriptions
- Create a new Company and archive the first Company in the Database
- Set a currency rate on a currency (i.e. Euro), then set that currency as the
Main Currency of the new Company.
- Then, set a currency rate on the previous Main Currency i.e USD.
- Create a Subscription Sales Order and confirm it.
- Open the MRR Breakdown report.
- Click into the data of the report.

Observation:
An error message will occur appear (Access Error)

Issue:
- when building the query, it also fetches the archived company, due to
`active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build
which fetches no data, leading to sort of access error
as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches.

Fix:
- we explicitly search for active companies

opw-5090463

Steps to reproduce the current behaviour:

- Update the DEMO user to be a website "restricted editor" and sales
"admin" who cannot bypass HTML field sanitization.

- As ADMIN, add a YouTube video to a product page > Save.

- As DEMO, try to update the content on the product page > You cannot
(a dialog informs you that you cannot edit the content because an admin
edited it previously).

Explanation:

Starting from [1], an HTML field can be flagged as `sanitize_overridable`
which allowed users with the `base.group_sanitize_override` group to
skip the HTML field sanitize process.

If such users added some content that is not considered "sanitize
friendly" (e.g. YouTube iframe), a restricted user won't be allowed to
add content in the fields, since the sanitizer will remove the original
content from the DOM.

For this case, the code from [2] added an implementation to consider the
field as none editable and warn the user once he tries to update it.

Implementation:

The goal of this commit it to fix the current limitation for video
upload that currently prevents non admin users to edit a website record
once an admin adds a video on it...

The idea of the fix is the following:

- We already have a technical fallback when uploading a video to save
the iframe `src` to an attribute: `data-oe-expression`.
- The public widget is now destroying the video iframes so they are
never saved in the DOM.
- A non-lazy code will build the iframes immediately on page load.
- The public widget can always create the iframes if they are not
already created (for compatibility).

[1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c
[2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6

task-3757205

…nse profitability

#### Issue:
While looking at project profitability, expenses analytic distribution are treated as being set to 100%.

#### Step to reproduce:
- With modules: project_{hr, sale}_expense, accountant
- enable "Analytic accounting"
- enable project > Timesheet
- Create a project "A"
- Set it as billable
- Create a Meal expense for an amount of 115$
- Set an analytic account of 50% for the project "A"
- Validate
- Approve
- Post journal entries
- Go to the project "A" > settings > Set Status

#### Current behavior:
- profitability display '-100'. It took the whole expense.

#### Expected behavior:
- profitability should display '-50'. Only 50% of the untaxed amount.

#### Cause of the issue:
- While querying `hr_expense`, the full untaxed amount of all expenses having the right `analytic_account` in their `analytic_distribution` were added together with no regard to the percent they were set to.

#### Solution:
- weight the expenses depending of their analytical distribution

opw-4949634

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