The Download PDF option of an article prints the page with the browser. On screen, the article body is inside .o_scroll_view_lg, which scrolls when the content is longer than the screen:

https://github.com/odoo/enterprise/blob/79f8defa04476e1b939dc8bb5449a775137aed62/knowledge/static/src/scss/knowledge_views.scss#L170-L177

The print stylesheet used to force overflow: visible on every div, so this container did not scroll when printing. It also hid every child of the body except the action manager, so the navbar and open dropdowns were left out of the print. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rewrote knowledge_print.scss to scope its rules to the Knowledge view and removed both rules. The scroll container now keeps its fixed height and its scrollbar when printing, so the scrollbar is drawn in the print preview and on every page of the PDF. The dropdown opened to reach Download PDF is printed on top of the article when it overlaps the page area, which happens when the browser is zoomed in.

Add overflow: visible to the print rule of knowledge_print.scss that already targets .o_scroll_view and .o_scroll_view_lg with position: static. That rule exists to undo the screen positioning of the scroll containers when printing, so the overflow reset belongs there. Its selector is also more specific than the screen one, so the value applies without !important, like position: static already does. Restore the rule that hides the body children other than the action manager, scoped to the Knowledge view like the rest of the file since the print stylesheet is now loaded on every page.

Before:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/44aa3366-3fc8-4382-8aa2-84625fa4b6d8" />

After:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/8b6eb2bc-37a3-4666-b871-0e6149c41fea" />

Steps to reproduce:
1. Open the Knowledge app and create an article
2. Paste enough text in the article to fill more than one PDF page
3. Zoom the browser to 200%
4. Click the three dots in the top right corner, then Download PDF
5. Check the print preview or the saved PDF

=> A scrollbar is drawn on the right edge of every page and the dropdown menu is printed on top of the article

Ticket [link](https://www.odoo.com/odoo/project.task/6279174)
opw-6279174

Forward-Port-Of: odoo/enterprise#120249

**Problem:**
When a team restricts automatic closing to specific stages
(from_stage_ids), the closing-reminder email is still sent to every
inactive ticket in the team, including tickets in stages that are
never auto-closed.

**Steps to reproduce:**
1. On a helpdesk team, enable Automatic Closing with a reminder and set
   "In Stages" (from_stage_ids) to one specific stage
2. Leave a ticket inactive in a different, non-folded stage until it
   reaches the reminder threshold (auto_close_day - reminder_delay)

**Current behavior:**
The ticket gets a "your ticket will be closed soon" reminder even
though it is not in an auto-close stage and will never be closed.

**Expected behavior:**
Only tickets that would actually be auto-closed (those in
from_stage_ids) should receive the reminder.

**Cause of the issue:**
The reminder selection filters on auto_close_ticket_reminder and the
reminder date only; unlike the auto-close selection, it does not apply
the team's from_stage_ids condition.

**Fix:**
Reuse the same stage condition used to select tickets for closing when
selecting tickets for the reminder, so the reminded set stays
consistent with the set that will be auto-closed.

opw-6291237

Forward-Port-Of: odoo/enterprise#120732

A paid order can reach `sync_from_ui` more than once. In that case the order falls into the else branch of `sync_from_ui` and its payments are re-processed through `process_saved_payments`, which was not idempotent and led to two issues:

- The change/return cash payment is generated server-side in `_process_payment_lines` and has no uuid, so `_update_lines` cannot deduplicate it. Each extra sync therefore created an additional return payment. It is now removed before being recomputed, which also keeps it correct when the payments are edited after payment (new return amount, or no change at all).

- `_update_lines` replays the client commands as-is. On a second sync, a delete command (`[2, id]`) targets a payment that the first sync already removed, and `_create_pm_change_log` crashed with a MissingError while reading the deleted record. Update/delete/unlink commands referencing records that no longer exist are now skipped. Note that delete/unlink commands only carry 2 elements, so the check runs before the `len(line) < 3` guard.

Steps to reproduce:
- Pay an order, then re-sync it (or edit its payments and sync again). => the return payment was duplicated, or a MissingError was raised.

opw-6327912

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

Forward-Port-Of: odoo/odoo#272539

This PR is needed for the fix of https://github.com/odoo/odoo/pull/272411

**Problem:**
lot's standard price are not correct 
when the product is fifo and move have 
different values and multiple lots

**Steps to reproduce:**
- product fifo tracked and valued by lots
- 20 IN @ 100 (all in lot 1)
- 10 IN @ 10 (5 in lot 1 and 5 in lot 2)
- on the product form click on the 
lot/serial number smart button and 
select lot 1

**Current behavior:**
the average cost of lot1 is 64
back on the product form the standard price is 
55

**Expected behavior:**
the average cost of lot 1 should be 20 * 100 (from move1) + 
5 * 10 (from move 2) / 25 = 2050 / 25 = 82
the standard price of the product should be 
2100 / 30 = 70

**Cause of the issue:**
Because the product is fifo, to compute 
the avg_cost of the lot we call _run_fifo()
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/stock_lot.py#L47
which calls _run_fifo_get_stack() to get the fifo
stack specific to this lot.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 1) 
run_fifo_get_stack() stores the on hand quantity (for the lot 
if a lot is given as param) in fifo_stack_size and, 
as long as there is moves and fifo_stack_size>0, 
adds move (starting from the last one in date) to the stack
and removes the quantity of the move from fifo_stack_size.
It then returns the moves stack and the remaning quantity 
on the first move of the stack (for the rest we know it's the 
full quantity)
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L612-L618

Inside run_fifo_get_stack(), to do this, because 
we're only considering the quantities from 
this specific lot we should only remove the quantity from 
the move that went in lot, but currently 
we're removing the quantity from the entire move.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L615-L618
So, at the first iteration of the while loop (for the move 
with 10 quantities), instead of doing 
fifo_stack_size(25) -= 5, we do fifo_stack_size(25) -= 10
The next move is the last one, so it's the one on which
remaining_qty_on_first_stack_move will be based on. 
remaining_qty_on_first_stack_move will be the minimum 
between the move's quantity and the fifo_stack_size. 
So because the fifo_stack_size is now wrongfully 
15 instead of 20 that's the value that will be returned
by _run_fifo_get_stack.

So inside run_fifo(), qty_on_first_move will be 15 instead of 20
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 2) 
Another issue is that inside _run_fifo when calling
_get_valued on the move, we don't use the lot 
parameter. So we use the entire quantity of the move 
instead of the quantity specific to the lot. 
https://github.com/odoo/odoo/blob/b07ff5843ee87741b293d9e67f72a77a2ed2ed88/addons/stock_account/models/product.py#L561-L562
And we use the full value of the move instead of 
the pro rata of the value for the quantity specific 
to the lot


As a consequence, inside _run_fifo the computation 
for the fifo_cost will be 
15 (because of issue1)  * 100 $ [first iteration of the while loop]
 \+ 10 (because of issue 2) * 10$ [second iteration of the while loop]
= 1600$
Instead of 20 *100 + 5 *10$ = 2050$

Therefore the avg_cost of the lot is wrong and the 
standard price of the product will also be false.

side note: those two issues balance each other if the price unit 
of the moves are the same

needed for PR of opw-6311341

Forward-Port-Of: odoo/odoo#274913
Forward-Port-Of: odoo/odoo#273728

Posting a message updates discuss_channel.last_interest_dt. Writing it on the channel row inside the request transaction holds a lock on that hot row for the whole transaction, so parallel posters pile up on it and crash with:

    could not serialize access due to concurrent update

Instead, under the message-post controller (mail_post_check_concurrency), record the new value as an append-only row in discuss.channel.last.interest.update. An INSERT never serializes against parallel posters and commits atomically with the message. The value is synced onto discuss_channel.last_interest_dt afterwards by a post-commit hook (a fresh transaction, hence a fresh snapshot that no longer conflicts), guarded by a non-blocking advisory lock per channel. The appended rows are durable, so a cron (ir_cron_discuss_channel_sync_last_interest_dt) drains anything the post-commit hook skipped, failed on, or never reached because its worker died — guaranteeing the channel is eventually bumped (a lost bump would mean a message is never surfaced). Reads and sorting keep using the indexed channel column.

With last_interest_dt no longer writing the channel row in the request transaction, livechat_failure goes back to a plain write, guarded so only the first agent message flips it; any rare residual conflict is handled by the regular request retry.

task-6321278


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

The following use case has been observed:

0. Customer start a payment from /shop/payment.
1. We received the webhook that notifies that the payment succeeded.
2. The payment post-processing cron start (it gather all the transactions that need to be processed, including the customer new transaction)
3. Meanwhile, the customer is redirected back by the payment provider to Odoo, which then redirect to /payment/status and start the payment post-processing for that specific transaction
4. The customer initiated payment processing finishes, he is redirected back to /my/orders/... page.
5. The payment post-processing cron finally start processing the same customer transaction and process it (a second time).

In that case, as the transactions to be post-processed backlog was quite high, there is consequent time between the time we gather all the TXs to post-process and actually process the customer transaction.

Also we don't end up with a `SerializationError` as the cron do commit after each transaction post-processing.

This commit force invalidate individual transaction cache values and recheck if it effectively still need to be post-processed before doing it.

opw-6332192

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

Forward-Port-Of: odoo/odoo#274725
Forward-Port-Of: odoo/odoo#274010

SurveyResult binds a click listener on each .filter-add-answer icon when it starts. The response tables are rendered by a separate interaction, SurveyResultPagination, which swaps the tbody through a t-out directive on every page change and on Show All. Those new rows are nodes SurveyResult never bound, so their filter icon does nothing and the page reloads on the unfiltered view.

The direct binding comes from https://github.com/odoo/odoo/commit/dfc1c742e35f75f2c386c4ef50d5584537ac1ed4, which replaced the jQuery delegated handlers that used to survive re-renders. https://github.com/odoo/odoo/commit/c2f0f681714fcb936ce058e8dd4f1b1e9fa7448c reattaches them on tab change but not on pagination or Show All, so only the first page works.

Bind updateContent on .pagination_wrapper, which holds the page links and the Show All button and stays outside the re-rendered tbody. A click on either bubbles up and rebinds .filter-add-answer on the rows that were just rendered.

Steps to reproduce:
1. Install survey
2. Create a survey with a Date question
3. Share it and record more than ten responses so the responses table spans several pages
4. Open the survey results page and click the list icon on the date question to show the User Responses table
5. Move to page 2 and click the filter icon on any row

=> The page reloads on the unfiltered view and the selected date is not applied

Ticket [link](https://www.odoo.com/odoo/project.task/6238514)
opw-6238514

Forward-Port-Of: odoo/odoo#268569

### Summary

When `dev_mode` includes `reload`, `ThreadedServer`'s FSWatcher reacts to a file change by sending the process a `SIGHUP` to trigger a phoenix restart. `signal_handler` turns `SIGHUP` into `KeyboardInterrupt`, which `ThreadedServer.run()`'s wait-loop catches. The catch is too narrow — a reload `SIGHUP` can kill the process through **three** windows that all sit outside the wait-loop's `try/except`, so the exception escapes `run()`/`main()`. Under Docker's default `restart: no`, PID 1 dies and the container stays down.

### The three windows

1. **Teardown duplicate (exit 130).** One file change can emit several FS events; the FSWatcher's `if not odoo.phoenix:` dedup races across threads and fires more than one `SIGHUP`. The first begins the phoenix teardown; the second lands during `stop()` / `watcher.stop()` / `_reexec()` and `KeyboardInterrupt` escapes.
2. **Exec-gap (exit 129).** `os.execve()` resets caught signal handlers to their default disposition (`SIGHUP` terminates) but preserves `SIG_IGN`; a `SIGHUP` arriving after the exec but before the re-exec'd process re-installs its handler kills the process outright.
3. **Startup (exit 130).** In the re-exec'd process, a `SIGHUP` anywhere in the startup section that precedes the wait-loop — `start()`, `preload_registries()` **and** `cron_spawn()` — escapes `run()`.

### Reproducer (deterministic)

Boot a `ThreadedServer` (`--workers 0`) on any initialised db, then signal PID 1 a few times in quick succession:

```bash
docker exec <container> sh -c 'i=0; while [ $i -lt 8 ]; do kill -HUP 1; sleep 0.1; i=$((i+1)); done'
```

Unpatched the process exits 130 or 129. Patched it stays up after one clean phoenix reload. Verified live on 17.0 and 18.0: stock `server.py` dies; the patched `server.py` survives sustained bursts (20/20 across repeated reload cycles on each version); `SIGINT`/`SIGTERM` still exit 0.

### Fix

Minimal, in `signal_handler` + `run()` + `_reexec()`; `SIGINT`/`SIGTERM` untouched; one new instance attribute, no new module globals:

- **Teardown duplicate:** ignore a `SIGHUP` once `quit_signals_received` is set (a restart/shutdown is already pending; the re-exec reloads fresh code).
- **Startup:** a per-instance `in_preload` flag marks the entire startup section (`start()` + `preload_registries()` + `cron_spawn()`); a `SIGHUP` there sets the phoenix flag + counter and returns instead of raising, so the wait-loop exits right after startup and runs the normal restart.
- **Exec-gap:** `signal.signal(signal.SIGHUP, signal.SIG_IGN)` just before `os.execve` so a `SIGHUP` in the gap is dropped rather than terminating the process.

### Related

- #21209 (merged) — introduced the phoenix flag; did not guard these windows.
- #206898 (merged), #207930 (open) — PreforkServer reload.

### CLA

Covered by Codeforward B.V.'s corporate CLA; #269240 adds me to its contributor list (pending merge).

Forward-Port-Of: odoo/odoo#273895
Forward-Port-Of: odoo/odoo#269247