**Steps to reproduce:**
* Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*.
* Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.).
* Save the settings.
* Create a *customer invoice*.
* Post the invoice.
* Send the invoice through *E-Invoicing (EDI)*.
* Open the generated *Invoice PDF* and the *form view*.

**Observed behavior:**
* The *IRN number* is correctly present in the *Invoice PDF*.
* However, it is *not saved/displayed* in the invoice form view.

**Cause:**
* The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available.

**Fix:**
* Inherit *_l10n_in_edi_send_invoice*.
* Add a condition after the invoice is sent and the JSON response is received.
* When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case).

opw-6097923

Forward-Port-Of: odoo/enterprise#115522
Forward-Port-Of: odoo/enterprise#114350

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

Steps to reproduce:
1. Install `appointment`
2. Create an appointment type with the followings
3. Schedule type flexible and a slot of 20 min.
4. Share this appointment and try to book appointment for 20 min.

Issue:
- 404 Error occurs after selectiong the slot

Cause:
- In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using
  slot.duration when building the booking URL for flexible slots.
  However, slot.duration is rounded to 2 decimals, so a 20-minute slot
  is serialized as 0.33 instead of its exact value.
  During validation, the end datetime is recomputed from this rounded duration,
  which no longer matches the original slot boundaries. This mismatch causes
  the slot to be considered invalid and the controller raises NotFound.

Solution:
- Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision.

opw-5924312

Forward-Port-Of: odoo/enterprise#108870

Problem:
Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small.

Solution:
Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold.

Before:
<img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" />

After:
<img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" />

Steps to reproduce:
- Change languange (French to have a long placeholder).
- Settings > Customer Invoices > Default Terms & Conditions.
- Check "Add a Note".
- Resize the screen to smaller size.
- Observe the power buttons overlap with the translate button.

task-6117734

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

Forward-Port-Of: odoo/odoo#261881
Forward-Port-Of: odoo/odoo#259094

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

## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**

## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:

https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203

It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.

The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.

opw-6089990

Forward-Port-Of: odoo/enterprise#115545
Forward-Port-Of: odoo/enterprise#114895

When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]`

This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]`

The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets

This commits fixes this two ways:

Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors

Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]`

Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example
`.test_method[test, with brackets\], and backslash\` will work the same way.

So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced.

Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests.

A followup pr will introduce the params to the canonical tag, and escape it as needed

Forward-Port-Of: odoo/odoo#262101
Forward-Port-Of: odoo/odoo#261516

**Description of the issue/feature this PR addresses:**
----------------------------------------------
When editing a message in a channel or group and opening the 'More
Actions' menu in the composer, the 'Start a poll' action is displayed
among the available options. Starting a poll while editing an existing
message makes no sense, as polling is only meaningful when composing
a new message.


**Current behavior before PR:**
----------------------------------------------
- 'Start a poll' action appears in the composer 'More Actions' menu even when the user is editing an existing message
- Clicking it while in edit mode opens the poll creation dialog, which is misleading and unintended behavior


**Desired behavior after PR is merged:**
----------------------------------------------
- 'Start a poll' action is hidden from the 'More Actions' menu when the composer is in edit mode
- The action continues to appear as expected when composing a new message in a channel or group conversation

Task-6171541

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

Forward-Port-Of: odoo/odoo#261961

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