When an employee's Income Stream Type is changed after a payslip has been created,
computing the sheet for payslip will raise a traceback.

Steps to reproduce the  error:
- Install ``l10n_au_hr_payroll_account`` module with demo data
- Switch to ``My Australian Company`` company
- Create a new payslip for ``Dennis Cactus`` Employee > Save
- Go to Employees > Open the ``Dennis Cactus`` employee >
  In Payroll tab, Income Stream Type: Other specified payments > Save
- Go back to payslip > click the compute sheet button

Traceback:
```py
KeyError: 'OSP'
```

https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L175-L178
The ``l10n_au_income_stream_type`` field on the payslip is a computed field that only depends on ``employee_id``.
As a result, changing the employee's Income Stream Type does not trigger a recomputation of the corresponding field on existing payslip.
So, when the ``payslip_ytd_totals`` field is computed, it uses the old value of ``l10n_au_income_stream_type`` field at [1], The resulting ``payslip_ytd_totals`` is then used to build the ``totals`` dictionary, and eventually, when the employee's current ``income_stream_type`` is used to access
``totals``, the mismatch key leads to the above traceback. https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll_account/models/hr_payslip.py#L75-L88

[1]: https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L269-L272

solution:

I added ``l10n_au_income_stream_type`` to ``add_to_compute()`` in ``compute_sheet()``.
This ensures that stale values of ``l10n_au_income_stream_type`` on
existing payslips are recomputed when the payslip sheet is computed.

sentry-7536819310

Forward-Port-Of: odoo/enterprise#123288
Forward-Port-Of: odoo/enterprise#120143

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#123216
Forward-Port-Of: odoo/enterprise#117879

Issue
-----
When using Sendcloud batch deliveries, users get a traceback if the transfer is split into multiple packages.

Steps to reproduce
-----
- Setup Sendcloud
	- Enable batch delivery
- Create a delivery for 2 units of a product
	- Delivery method set to sendcloud
- Put each unit in a separate package
- Validate the delivery

> Traceback

Cause
-----
Bug introduced by #90302 (so only present in 19.3+).

When using the batch deliveries option, the packages are sent in a single list. This means that, in `_prepare_parcel`, when we iterate over the packages, `pkg` can be a list

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L462

This means that `pkg.name` will fail

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L481

Considering that a batch delivery uses the same reference number on all labels, we can pass `None` as a fallback to `_get_unique_order_number_reference` (it is an accepted value)

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L388-L393

-----
Ticket:
opw-6267928

Forward-Port-Of: odoo/enterprise#120206

Issue
-----
When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end.

`content/exportDeclaration/invoice/number: expected type: String, found: Boolean`

Steps to reproduce
-----
- Create a Belgian company
- Setup DHL
	- DHL Product D - Express Worldwide
	- Dutiable Material enabled
- Create an amrican customer
- Deliver a product to the american customer

> Validation Error

Cause
-----
The field is populated in

https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/delivery_dhl_rest/models/dhl_request.py#L204

The problem is that `next_by_code` uses the company found in the env, whereas the sequence's company is the main one, so it is not found when doing

https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/odoo/addons/base/models/ir_sequence.py#L287

-----
Ticket:
opw-6171886

Forward-Port-Of: odoo/enterprise#123170
Forward-Port-Of: odoo/enterprise#118379

The `body` field on `whatsapp.message` was defined with `related_sudo=False` with the intent of restricting access to messages from restricted records. However, this was never actually providing any security value because [`mail.message.fetch()`] was overriding it with `self.sudo()` till `v19.1`, meaning the body was always fetched as superuser regardless:
```py
    web_search_read() -> search_fetch()
    -> fields.py _compute_related()
    -> record[self.related_field.name]  # triggers fetch of mail.message.body
    -> models.py _fetch_field()
    -> mail_message.py fetch()
    -> self = self.sudo()  # sudo hack overrides related_sudo=False silently
```
In `v19.2`, the `fetch()` sudo hack was intentionally removed (see commit odoo/odoo@4727f12d274a0b2d7c455363d189565bd8fb2e7a) as access rights are now cached and can be checked without a performance penalty. This exposed the broken `related_sudo=False` which now causes an `AccessError` when trying to read the body of a `whatsapp.message` whose linked `mail.message` points to a document the current user cannot access (e.g. `purchase.order`).

Access control on `whatsapp.message` is already correctly enforced at the `ir.rule` level:
- Regular users can only see messages they created (`create_uid = user.id`)
- WA Admins can see all messages

We have upgrade requests failing on this issue: TBG-[2765]

[`mail.message.fetch()`]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/models/mail_message.py#L812-L819
[2765]: https://upgrade.odoo.com/odoo/tbg/2765?debug=1

Forward-Port-Of: odoo/enterprise#119867

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

When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning.

Steps to reproduce:
-------------------
* Install barcode and stock
* Enable packages in settings
* Open Inventory
* Create a product,
* Create a Package Type -> barcode PACKTYPE,
* Create a Package linked to this package type -> PACK,
* Add at least 2 unit of product to this package,
* Create a delivery for 2 unit of the product,

Open Barcode
* Operation > Delivery orders > your delivery
* Erase the destination package from the first line
* Scan PACK
( don't click on the green line)
* Scan PACKTYPE

**Actual behavior**
create a new package but does not link it to the new products

**Expected behavior**
create a new package and set it as destination package.

Observation:
-------------
When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected:
https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090

When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType```  
where we will obtains packagesIds checking that we have a source package:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132
and will send us to ```_putPackInPack```:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136

Where we will avoid the empty packageIds since we checked on the source package and not the destination package:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299
and will call ```action_put_in_pack``` from the packaging model:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306

In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made.

Which means that in our case, we created a package without linking it to anything.

Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line :
https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117
It will not show the new package in barcode


opw-5449729

Forward-Port-Of: odoo/enterprise#120335
Forward-Port-Of: odoo/enterprise#104876

Steps to Reproduce
---
- Create two different working schedules with different public holidays
- Assign employees to specific working schedules
- Set company default working schedule to a different schedule
- Login as employee with specific working schedule
- Navigate to Timesheets app -> My Timesheets
- Observe public holidays and personal time-off displayed in the timesheet grid

Issue
---
- The timesheet grid displays unavailable dates (public holidays, weekends) from the company's default working schedule instead of the employee's assigned working schedule.
- Personal time-off requests are not reflected as unavailable dates in the timesheet grid.

Current Behaviour
---
- Public holidays shown are always from the company's default working schedule, ignoring employee-specific working schedule assignments.
- Employee's approved time-off requests don't appear as unavailable in the timesheet.

Expected Behaviour
---
- Public holidays should display based on the employee's assigned working schedule, with company schedule as fallback only when no specific schedule is assigned.
- Employee's personal time-off requests should appear as unavailable dates.
- This should align with Time Off app behavior.

Fix
---
- Included employee-specific work interval calculation with personal time-off requests.
- Added support for contract-based calendar changes and calendar validity periods.
- Implemented proper fallback when valid intervals are not found.

task-4997080

Forward-Port-Of: odoo/enterprise#123331
Forward-Port-Of: odoo/enterprise#95458

**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

Issue before this commit:
=========================
When splitting a done picking that contains at least one stock move whose
done quantity is less than the demanded quantity (product_uom_qty),
an expected singleton traceback occurs.

Steps to Reproduce:
=========================
- Install the stock module with demo data.
- Create a delivery picking for any product with a demand of 5.
- Set the done quantity to 2.
- Validate the picking without creating a backorder.
- Try to split the validated/done picking.
- An expected singleton traceback is raised.

Cause of the issue:
=========================
Previously, attempting to split a done picking simply returned because 
there was nothing left to split.

After this [PR](https://github.com/odoo/odoo/pull/224952), the split action calls **message_post()** to post a note on the original picking 
of the generated backorder. However, no backorder is created when splitting a done picking
since there is no remaining quantity to split. As a result, message_post() is called on 
an empty recordset, leading to an expected singleton traceback.

With This Commit:
=========================
Splitting a done picking has no functional purpose, as there is nothing left to split.
In this case, simply return without performing any action. This preserves the 
previous behaviour and prevents the traceback.

Forward-Port-Of: odoo/odoo#274855
Forward-Port-Of: odoo/odoo#274382

Description of the issue/feature this PR addresses:
This PR resolves an integration failure with the Nilvera e-invoicing provider when a company’s primary currency is configured to a foreign currency (e.g., USD) rather than the local currency (TRY). Nilvera strictly requires a valid exchange rate relative to Turkish Lira (TRY) to be included inside the XML nodes of every posted invoice utilizing a foreign currency.

Functions affected:

def _add_invoice_exchange_rate_nodes(self, document_node, vals):

def _l10n_tr_get_currency_conversion_rate(self, invoice):

Current behavior before PR:
When generating an invoice where both the company's main currency and the invoice currency are foreign (e.g., USD), the system does not calculate or embed a TRY conversion/exchange rate into the invoice payload. Because this mandatory local currency reference mapping is missing, Nilvera rejects the invoice submission.

Desired behavior after PR is merged:
For every invoice processed via the Nilvera localization, the system will explicitly calculate and inject the exchange rate between the active invoice currency and TRY into the posted document nodes, regardless of what the underlying company's primary currency is set to.




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

Forward-Port-Of: odoo/odoo#271129
Forward-Port-Of: odoo/odoo#270531

On a mo that has byproducts, if you unreserve, it will also set the quantity of byproducts to 0

Steps to reproduce:
-------------------
* Create a Products main, component and byproduct
* Create a bom for main with component as component and byproduct as byproduct
* Create and confirm a mo for main
* Set qty_producing to quantity ot produce
* click on "Unreserve" (do_unreserve)
* click on "Check availability"  (action_assign)
* Produce All
-> the byproducts will not be produced.

 Observation:
-------------
When updating the qty_producing value it will also update the quantity of the byproducts moves:
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L892-L893
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mrp/models/mrp_production.py#L1350
https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/stock/models/stock_move.py#L2382
The quantity on the byproducts move has been updated.

When clicking on Unreserve it will call do_unreserve,
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L2297-L2298
It will filters the moves that do not need to be unreserved and select the others:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L900
and it will unlink all the sml from the moves:
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/stock/models/stock_move.py#L919
Which will set the quantity on the byproduct moves to 0.

When Producing all (button_mark_done) since the qty_producing has already been set, it will simply mark the byproduct move has picked.
https://github.com/odoo/odoo/blob/aca2e226143487b421f79194d677bb48d5da1358/addons/mrp/models/mrp_production.py#L1323-L1324

In our case, this means that the no byproducts will be created since, the quantity was previously set to 0

opw-6296562

Forward-Port-Of: odoo/odoo#273739
Forward-Port-Of: odoo/odoo#272216

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

This PR improves the cost of `/forum/my-forum-1/my-slug-1234` by ~48%.

This has a huge impact on odoo.com

The `/forum/...` routes are the `#1` on odoo.com in terms of absolute count and in terms of CPU and SQL cost. They are called several million times a day. 

The average total time for `/forum/my-forum-1/my-slug-1234` goes from ~358ms to ~187ms (sql: 107ms -> 52ms - cpu 250ms -> 135ms)

This has been tested by extracting 30k real forum post urls from odoo.com logs and replaying them on a staging server. That day `/forum/...` routes were called 2.8M times

## before
<img width="1343" height="122" alt="image" src="https://github.com/user-attachments/assets/2b8264b7-4f26-40a7-a20a-20d478f5a93a" />

## after
<img width="1339" height="124" alt="image" src="https://github.com/user-attachments/assets/7c73aeb0-a4b4-45b8-ae98-093ac70c438e" />



### First commit

before
<img width="1857" height="946" alt="image" src="https://github.com/user-attachments/assets/63b9d966-f5fd-4047-b4cb-533b7e9491bc" />


after

<img width="1844" height="867" alt="image" src="https://github.com/user-attachments/assets/9494efe0-0b7c-419d-b918-dcfe5e942e63" />


query plan for most used tags as public user:

- with the index https://explain.dalibo.com/plan/gbf9fbd358687f3e
- without the index https://explain.dalibo.com/plan/da5gg6cd27f67496

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

Forward-Port-Of: odoo/odoo#274683
Forward-Port-Of: odoo/odoo#272716