Steps to reproduce:
===================
1. Open the To-do app and pick any task.
2. In the description add text and an icon with a bg color.
`(you can add this: <i class="fa rounded rounded-circle fa-user
bg-o-color-1 fa-4x" contenteditable="false">​</i>)`
3. Select all and click "Remove format".

Result:
-> Traceback due to an infinite loop.

Cause:
======
Remove format calls `removeAllColor()`, which loops forever at:
https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194

Why:
_applyColor doesn't remove the icon's background class, so
hasAnySelectedNodeColor keeps returning true and the removal loop
never terminates.
This happens because `font` is already the `<i>` element with the `fa`
class, using `querySelectorAll` on it won't include the element itself,
so the icon is never checked or updated.
https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290

Solution:
=========
Check if the font itself has the fa class before doing the
`querySelectorAll`, and include it in the nodes to check for color.

Test Impact:
============
Before this fix, a `<span>` containing an icon was wrapped in a `<font>`
when applying color, treating the icon as a normal span (without size)
instead of applying the color directly.
https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397

opw-5928627

Forward-Port-Of: odoo/odoo#261405
Forward-Port-Of: odoo/odoo#248449

1. The `MPESA` payment method needs a callback url where it does a
   `POST` request with the transaction details. Since the call comes
   from safaricom, CSRF will block those requests. This commit will
   disable CSRF checks on the callback endpoints which are expected to
   be called from an external service
2. Sometimes the `web.base.url` parameter is automatically set to http.
   But safaricom expects https for all the urls. So we need to ensure
   that the urls we send on `lipa_na_mpesa_register_urls` use https,
   otherwise the registration fails with an `invalid url` error.
   Additionally, I added the error message in case of error
4. In addition to the business short code we also need a till number for
   transactions. Since this is stable, I've added the till number as an
   extension of the business shortcode field and then parse it before
   usage. On master there is a new PR which will properly separate the
   fields

Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833)

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

Forward-Port-Of: odoo/odoo#254993

When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448

Forward-Port-Of: odoo/enterprise#115341
Forward-Port-Of: odoo/enterprise#115241

### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.

### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?

### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67

### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.

opw-6050537

Forward-Port-Of: odoo/odoo#260145

When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer.

This caused two issues:
- CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted.
- CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children.

Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct.

Also align the mock server with the real server behavior:
- Place the span *inside* the last `div`/`p` element instead of after it.

Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label.

task-6172161



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

## Problem:
During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests.

## Solution:
Enforce the `limit` when fetching if it is present.

## Steps to reproduce:
- Have a product with many quant records
1. Open a picking for this product in Barcode
2. Change the lot/serial

The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve.

## Benchmark:
<table>
	<thead>
		<tr>
			<th># of quants</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>17193</td>
			<td>~9s</td>
			<td>~400ms</td>
		</tr>
	</tbody>
</table>

opw-6041705

Forward-Port-Of: odoo/odoo#261904
Forward-Port-Of: odoo/odoo#259983