Currently, an error occurs when a user attempts to pay an invoice.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):**

 - Install the `Accounting` module.
 - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`.
 - Go to `Invoices` and `create a new Invoice`.
 - Add one invoice line and set the `Payment Term` to the `newly created payment term`.
 - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden).
 - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`.
 - Now `Confirm the invoice` and `Click on Pay`.

**Error:**
`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

**Cause:**
This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised.
Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error.

**Fix:**
This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above.

[1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703

[2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635

[3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305

[4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522

sentry-713241246

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

Forward-Port-Of: odoo/odoo#241060

**Issue 1:**

Steps to reproduce:
- Insert a icon in an empty paragraph.
- Remove the inserted icon.
- The paragraph becomes unreachable.

Cause:
- When a paragraph contains only an icon, removing that icon during the delete process does not trigger `fillEmpty`. As a result, the paragraph ends up with no content, leaving it empty and unreachable.

Solution:
- During the delete process, after the icon is removed, call the `fillEmpty` method. This ensures that if the block becomes empty, a `<br>` is inserted inside the paragraph, keeping it accessible.


**Issue 2:**

Steps to reproduce

- Insert an icon in an empty paragraph.
- Place the cursor before the icon.
- Press Enter.
- Nothing happens.

Cause
- When the cursor is placed before a `contenteditable=false` element, `getDeepRange` sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context.

Solution

- Instead of setting the selection inside `getDeepRange`, set the selection after calling `getDeepRange` only if the returned range is not within a `contenteditable=false` element.

task-3540454

Forward-Port-Of: odoo/odoo#241125
Forward-Port-Of: odoo/odoo#237891

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging with a barcode to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and to scan it.
8. Now scan the barcode of the packaging
-> It triggers an traceback

### Cause of the issue:
The product_id and their uom_uom that are in the move_lines are added in the cache:
https://github.com/odoo/enterprise/blob/d0a7619bb87fb1fad45451a1c79dca73994ee8bd/stock_barcode/models/stock_picking.py#L92-L94
However the kit product and the product_uom are not added in the cache, since they are not in the move_lines ( the components are in the move_lines not the kit product).

In _get_barcode_data, where it's supposed to retrieved the product_uom (packaging in previous version, see (1)), it retrieve the uom_uom of the products again: https://github.com/odoo/enterprise/blob/4d3c33ed152f014e4965613756845fb054c9f2bc/stock_barcode_mrp/models/stock_picking.py#L12-L17

For the scan of the packaging barcode to work properly it also need the corresponding product_id, because if the product_id it's not present an it will raise and error:
https://github.com/odoo/enterprise/blob/6e2c39ea2898e870f348e0bbe4ad29abe35794b6/stock_barcode/static/src/models/barcode_model.js#L1104-L1108
https://github.com/odoo/enterprise/blob/6e2c39ea2898e870f348e0bbe4ad29abe35794b6/stock_barcode/static/src/models/barcode_model.js#L1635
https://github.com/odoo/enterprise/blob/6d4fe2b03b7d981e3092e42d1b5e1786734d9427/stock_barcode/static/src/lazy_barcode_cache.js#L102-L115

(1) Changes from this commit:
https://github.com/odoo/enterprise/commit/b4f285138edc227050c89c92fd15d39fb656da6b
"This commit removes `product.packaging` model completely and merges it
into units of measure feature."

The packaging changed in a new model called product.uom that is the link between the product and it's uom.uom

opw-4852875

Forward-Port-Of: odoo/enterprise#87867

overlook of https://github.com/odoo/odoo/pull/239717
### Before this commit:
Runbot was red on weekends, as there are no work intervals on weekends.

### After this commit:
Use Friday as a fallback on weekends. In addition, improve the test performance by mocking the total number of weeks of planning to 2 instead of 50 (before: 6s, after: 1s).

runbot-237575

---

Note: ran the test for the next 5 years, and it works :+1: 
```diff
diff --git a/addons/mrp/tests/test_bom.py b/addons/mrp/tests/test_bom.py
index 7acf19e89add..bfadc8e487c1 100644
--- a/addons/mrp/tests/test_bom.py
+++ b/addons/mrp/tests/test_bom.py
@@ -13,6 +13,7 @@ from odoo.tests.common import HttpCase, tagged, freeze_time
 from odoo.tools import float_compare, float_round, float_repr
 
 
+@tagged("-at_install", "post_install")
 @freeze_time(fields.Date.today())
 class TestBoM(TestMrpCommon):
 
@@ -963,6 +964,16 @@ class TestBoM(TestMrpCommon):
             self.assertEqual(report_values['lines']['operations_time'], 15.0)
             self.assertEqual(report_values['lines']['producible_qty'], 2)
 
+    def test_bom_report_planning_with_producible_qty_loop(self):
+        from datetime import date  # noqa: PLC0415
+        start, stop = date.today(), date.fromisoformat("2031-01-01")
+        with freeze_time(start) as frozen_date:
+            for i in range((stop - start).days):
+                print("date:", str(date.today()))
+                with self.subTest(str(date.today())):
+                    self.test_bom_report_planning_with_producible_qty()
+                    frozen_date.tick(timedelta(days=1))
+
     def test_21_bom_report_variant(self):
         """ Test a sub BoM process with multiple variants.
         BOM 1:
```

Forward-Port-Of: odoo/odoo#241582

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later.

It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this
upgrade script: https://github.com/odoo/upgrade/pull/9153

1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it.
2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout`
3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12
4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore
5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie
6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1

Forward-Port-Of: odoo/odoo#241129

Steps to reproduce:
-------------------
1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order
2. From PoS, make an order, select it to invoice, and click the pay button.
3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed).
4. Come back to the initial page, a traceback will appear and the ticket is not printed.

Why it happens:
---------------
The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`!

The fix
-------
Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`.

opw-5124585

Forward-Port-Of: odoo/odoo#241781
Forward-Port-Of: odoo/odoo#239008