During an `DomPlugin.insert`, the inserted content is added.
Then some transformations are applied to clean up, including the
removal of some nodes which are inventoried into
`candidatesForRemoval`, and some specific `<br>` nodes.
Ultimately, the selection is set after the last inserted node.

In some cases, none of the inserted content remains after the clean up.
When this happens, the selection is being set after the last
inserted node, which is not part of the DOM anymore, and therefore
leads to an error.

This commit prevents this from happening by detecting when all inserted
content was actually already removed.

Steps to reproduce:
- In a plain web page, copy a <br> into the clipboard
- In an editor, put a character on a line
- Paste

=> An error popup was displayed

task-5429909

[FIX] html_editor: avoid failing when selection nodes are disconnected

This commit addresses a traceback that was spotted but for which the
actual scenario remains undetermined.
The only possible way this traceback may occur is if nodes inside a
selection are disconnected.

The test added by this commit produces the same traceback as the
observed one.

task-5429909

Forward-Port-Of: odoo/odoo#242941
Forward-Port-Of: odoo/odoo#242488

Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line.

## Steps to reproduce
1. Create an expense paid by the company.
2. Confirm and generate the expense report.
3. Reset the expense’s journal entry to draft and add an analytic account on the first line.
→ An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited.

## Cause
For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*.
In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes.

However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`.
This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines.
As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate.

## Solution
Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`.

**opw-5166707**


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

Forward-Port-Of: odoo/odoo#243052
Forward-Port-Of: odoo/odoo#233841

This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled.
It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator.

### Add warnings when some model/field could not be deleted

The uninstallation process tries to delete all the records created by the modules being uninstalled.  It uses a best-effort strategy, i.e., it skips the records that cannot be deleted, whatever the reason.  But some records are very likely to cause problems, namely `ir.model` and `ir.model.fields` records, because skipping them implies not cleaning up their corresponding table's schema.

For instance, if a column is not dropped, reinstalling the corresponding module will possibly cause inconsistencies, because
 - the column contains old values for existing records, which won't be recomputed (if the field is computed);
 - the column contains NULLs for records created between the uninstallation and the reinstallation of the module.

We therefore add a warning in those cases, in order to detect and fix those potential issues as soon as possible.

### Make ondelete decorator work as documented

A method decorated with `@api.ondelete(at_uninstall=False)` should be called except when the method's module is being uninstalled.  Currently the method is skipped when *any* module is uninstalled.

The fix consists in adding the set of modules being uninstalled in the attribute `registry.uninstalling_modules`, which may be used to detect uninstallation and determine which modules are being uninstalled.

### Replace MODULE_UNINSTALL_FLAG by new conventional flag 'force_delete'

We turn constant `MODULE_UNINSTALL_FLAG` into an explicit conventional flag, and rename it `force_delete` for the sake of simplicity.  The idea is to decouple the flag from uninstallation.  The caller simply uses
```py
records.with_context(force_delete=True).unlink()
```
to bypass some deletion hooks, which typically prevent deletion by raising some exception, in order to avoid data inconsistencies.  On the callee's side, one has to explicitly detect the flag and skip the checks, like in:
```py
@api.ondelete(at_uninstall=False)
def _prevent_deleting_confirmed(self):
    if self.env.context.get('force_delete'):
        return
    if any(record.state == 'confirm' for record in self):
        raise UserError(_("You cannot delete confirmed records!"))
```
Note that the uninstallation process uses the convention by automatically adding `force_delete=True` in the `context` for deleting records.

### Fix issue module mail uninstallation

Two overrides of `unlink()` on models `ir.model` and `ir.model.fields` fail when uninstalling module "mail", because their code relies on some columns and those columns have been dropped already.  This causes some table and column to remain after uninstallation.  When reinstalling module "mail", errors like follows are logged:
```
column "mail_message_id" of relation "mail_tracking_value" contains null values
```
The fix consists in turning the overrides in proper "ondelete" methods, which are skipped when module "mail" is uninstalled.


https://github.com/odoo/enterprise/pull/103651

**Descripion of the problems**
When the content of a popup is deleted, two problems happen:
1. The popup stays open displaying an empty white rectangle.
2. Options relative to the last removed element are still displayed and produce an error if the user interacts with them.

**How to reproduce**
Drop the snippet `s_popup`, and remove the "Block" element.
Problems: 1. the popup is still open but empty, 2. the "Block" options are still displayed.

**Origin of the problems**
Problem 1 happens simply because nothing takes care of removing empty popups.
Problem 2 happens because `RemovePlugin.removeCurrentTarget` set the `nextTargetEl` without first checking if the element is activable or not. Thus, when removing the last block in a popup, the next target is set to the `.o_we_no_overlay` close button, despite it being not activable. As a result, when `BuilderOptionsPlugin.updateContainers` is called, it does not update containers because the target is not activable. Thus, the "Block" options are still displayed despite the element being removed.

**Fix**
Both problems are fixed by changing `RemovePlugin.isEmptyAndRemovable` such that empty popups are marked as removable.

task-5401692

Forward-Port-Of: odoo/odoo#242377
Forward-Port-Of: odoo/odoo#239507

Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237)

---

There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session.

In addition, if a session is already open, it is no longer possible to resolve the situation:

* From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method.
* From `pos.config`: the payment methods field is read-only when there is an open session.

We had to delete one of the online payment methods from the database directly to be able to open the POS session again.

To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method.

Forward-Port-Of: odoo/odoo#240343

Issue before this commit:
=========================
Searching for Delayed Productions in the MRP list view triggered:
- A deprecation warning in saas-18.4 → 19.0:
`warnings.warn("Since 19.0, use Domain.custom(to_sql=lambda model, alias, query: SQL(...))", DeprecationWarning)`
- A traceback in master:
`Failed to cast TableSQL('mrp_production', -, None).date_finished into a datetime`

Steps to Reproduce:
=========================
- Install mrp module.
- Open the Manufacturing Orders list view.
- Filter by Delayed Productions.
- Observe the warning (saas-18.4 → 19.0) or traceback (master).

Cause of the issue:
=========================
Recent ORM changes in [PR](https://github.com/odoo/odoo/commit/f811af2c52df798b6ba0fc18e3f45944abdb7a12) disallow using raw SQL expressions as values inside normal domains. 
Only Domain.custom() is permitted for injecting custom SQL.
The previous _search_is_delayed implementation used a deprecated pattern, 
which caused the warning in current versions and a crash in the master version.

With This Commit:
=========================
- Rewrite the delayed production filter using Domain.custom() to safely generate the SQL.
- Preserve functional behaviour: the filter still returns delayed productions correctly.
- Avoid deprecation warnings and prevent traceback.

TaskID:- 5404547

Forward-Port-Of: odoo/odoo#243134
Forward-Port-Of: odoo/odoo#239574