Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice >

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

opw-6158881

Forward-Port-Of: odoo/enterprise#117011

Issue:
When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers.

Steps to reproduce:
1. Start a survey that includes a time limit.
2. Disconnect your device from the internet just before the timer runs out.
3. Wait for the timer to reach zero, triggering the auto-submit.
4. Reconnect to the internet and attempt to click "Submit" manually.
5. The action is ignored and the form remains stuck.

Cause:
To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen.

Solution:
Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure.

Task-5787410

Forward-Port-Of: odoo/odoo#249514

Since this [PR](https://github.com/odoo/odoo/pull/252738),
The test `show looking for help duration in the sidebar` was failing due to 
a race condition.

With the following error:
```
expected at least 1 element after 200ms and found 0 elements: 5 matching 
:text(Visitor #1) (1 element containing selector :text(Visitor #1) > 0 text 
elements)
```

The test was going through the join flow, which triggers `discuss.channel/joined`
and then `fetchChannel()`. Since `fetchStoreData()` is debounced, the resulting
`/mail/data` fetch could race with the later `/im_livechat/session/update_status`
call and the corresponding bus/store updates. Because the test was asserting the
timer while those async updates were still settling, it could sometimes
observe an intermediate client state and fail.

This commit fixes the race condition to wait for the `/mail/data` RPC
to fully complete, before clicking the `Looking for help` button.
This ensures the store is fully settled before the LFH timer assertion,
making the test deterministic.

runbot-[242278](https://runbot.odoo.com/odoo/error/242278)

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

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

Forward-Port-Of: odoo/odoo#264240
Forward-Port-Of: odoo/odoo#263586

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b6a68b89c1 [REL] 19.1.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9087d404c4 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050)
https://github.com/odoo/o-spreadsheet/commit/6255eb07a6 [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/aea4a8c55f [REL] 19.1.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/addcd227d8 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5e333513e4 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/dedcb6a12c [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e267f5db92 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1d4311e3d2 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dfff07841c [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2e87404919 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

The `show looking for help duration in the sidebar` test has been flaky since [1].

The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`.

 This creates several race conditions:
- Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data.
- Channel state fetched after the user joins via `/mail/data`.

The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed.

This commit splits the test to preserve coverage while avoiding the problematic rapid state transition.

runbot-242278

[1]: https://github.com/odoo/odoo/pull/252738

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

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264381
Forward-Port-Of: odoo/odoo#241827

**Steps to reproduce:**
1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator.
2. Create a SO, create invoice, confirm, and send.
3. Now go back to the SO, and try to link the INV document to the chatter.

**Cause:**
When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document.

**Solution:**
Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework.

opw-5916364

Forward-Port-Of: odoo/enterprise#107723