Steps to reproduce:
------------------------------------
1. Install the Knowledge module.
2. Open any article.
3. Click the header icon. If no icon is present, add one from the Actions menu.
4. Click the header icon again.
5. Click Remove icon from the emoji picker.

Observation:
------------------------------------
A traceback is raised when removing the header icon. 
```
TypeError: Cannot set properties of undefined (setting 'scrollTop')
```

Issue:
------------------------------------
The emoji picker component updates its scroll position through a grid reference.

After this PR - https://github.com/odoo/odoo/pull/269588, the emoji picker was migrated to Owl 3, which changed the way component references are handled. The header icon removal flow still uses the previous ref access pattern, causing the grid reference to be `undefined` when attempting to update `scrollTop`, resulting in a traceback.

Solution:
------------------------------------
Update the syntax for accessing the ref signal.

### Description of the issue/feature this PR addresses:
International production payments processed via Redsys are failing with error code 9754 (SIS0754). This rejection occurs because the EMV3DS (3D Secure 2.0) payload is sending the billAddrState field with an invalid ISO code format for non-Spanish customers or customers without a state configured.

### Current behavior before PR:
The _redsys_prepare_merchant_parameters method hardcodes the billAddrState key into the DS_MERCHANT_EMV3DS dictionary payload. If self.partner_state_id.code is missing or empty, Odoo sends an empty/falsy value. Because Redsys enforces strict EMV3DS format validation, it rejects the entire transaction for having an invalid state format rather than simply ignoring the empty value.

### Desired behavior after PR is merged:
The DS_MERCHANT_EMV3DS dictionary is now constructed dynamically. The billAddrState key is only appended to the payload if a valid state code actually exists for the partner. RedSys allows this field to be optional, so omitting the key entirely when unavailable causes Redsys to skip the validation for that specific field, allowing certain international payments to process successfully.

opw-6237764

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

Forward-Port-Of: odoo/odoo#274912
Forward-Port-Of: odoo/odoo#270899

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#275119
Forward-Port-Of: odoo/odoo#264039

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#121885
Forward-Port-Of: odoo/enterprise#121693

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#275119
Forward-Port-Of: odoo/odoo#264039

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

**Issue:**
Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in
https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e

**Fix:**
The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note.

**Steps to reproduce:**
1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save
2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate
3. Go back to the settings and set "Send payslips to employees" to When Confirmed
4. On the payslip, click Pay, then Mark as Paid
5. Click Print so the payslip document is generated
6. Click Send By Email and send the mail
7. Check the payslip chatter

=> The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before

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

`_add_manual_models` builds Python model classes for custom ("manual") `ir.model` records with a raw `SELECT *` on the `ir_model` table, then hands each row to `_instanciate_attrs`, which reads a fixed list of expected columns (`model`, `name`, `abstract`, `transient`, `order`, `fold_name`, `info`) via dict subscription (`model_data['xxx']`).

This assumes every one of these fields is always backed by a real database column. That assumption breaks whenever a field originally declared as stored on `ir.model` gets redeclared as non-stored (`store=False`) by another module inheriting the same model: Odoo correctly drops the now-unneeded column during that module's `_auto_init()`, but any code still doing `SELECT *` on the table no longer gets that key in the result row, and the subscript access raises a bare `KeyError`. This aborts the *entire* registry load, for every model in the database, not just the one whose field changed -- because `_add_manual_models` runs once per registry load and any database with at least one manual/custom model exercises it.

This is exactly the scenario introduced by 267bec440d56 ("[IMP] base: add IrModel.abstract field"): it added a new, plain stored `abstract` field on `ir.model`. `web_studio` has independently defined its own `abstract` field on `ir.model` since 2016 (ac1129f6577), as a computed, `store=False` field. Once both are loaded together, Odoo's field- merging logic settles on the `store=False` definition, so `_auto_init()` drops the `abstract` column -- and any database that also has at least one manual model (built through Studio, or via a module that dynamically generates SQL-view-backed models) then fails to boot its registry at all:

    File ".../odoo/orm/model_classes.py", line 554, in _add_manual_models
        attrs = env['ir.model']._instanciate_attrs(model_data)
    File ".../odoo/addons/base/models/ir_model.py", line 487, in _instanciate_attrs
        '_abstract': bool(model_data['abstract']),
    KeyError: 'abstract'

Fix `_instanciate_attrs` to fall back to a sane default instead of assuming the column exists. This doesn't just patch the `base`/ `web_studio` collision -- it hardens `_add_manual_models` against any future field made non-stored by an inheriting module, which is otherwise a silent, whole-database-breaking failure with no visible relation to whichever module actually changed the field.

A companion fix removing web_studio's now-redundant override (the actual root cause of the collision) is proposed separately.

Steps to reproduce:
1. Install `base` and `web_studio` together (or in either order) --
   Odoo's field-merging settles on web_studio's `store=False`
   definition, but leaves the `abstract` column physically in place;
   it is not dropped automatically.
2. Have at least one manual model in the database (`state='manual'`
   on `ir.model`, e.g. created through Settings > Technical > Models).
3. Actually remove the now-orphaned `abstract` column -- e.g. via the
   OCA `database_cleanup` module's column-purge wizard
   (`cleanup.purge.wizard.column`), which explicitly targets exactly
   this kind of column (computed + non-stored fields are excluded
   from its "keep" list, so `abstract` gets flagged and dropped).
4. Restart Odoo / reload the registry: it fails to boot entirely with
   a KeyError on that field name, for every model, not just the one
   whose owning module changed.


Related: odoo/enterprise#123572



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

Forward-Port-Of: odoo/odoo#275092

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

Problem:
When filtering lost leads and grouping them, the lost leads are not counted in the groups' totals.

Steps to Reproduce:
1. Go to CRM
2. Go to Reporting > Leads
3. Select List View
4. Before applying any grouping, check the total number of leads and
make sure there are some closed leads among the leads and that the
applied filter includes the inactive/lost leads
5. Apply any grouping
6. Check how the sum of the groups totals doesn't equal the leads total

Cause:
When reading a group, the domain from the applied filter gets optimized, meaning that the applied rules get simplified logically.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/web/models/models.py#L421
When looking for all leads, we filter by both active and inactive leads, but the optimize method removes both of them since active=TRUE OR active=FALSE = TRUE always. When removed, no filtering on the active field is in the domain now, which leads to the search method returning only active leads (default behaviour of search method when the active field is not set in the domain).

opw-6302388

Forward-Port-Of: odoo/odoo#272390

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set.

When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload.

unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records.

Steps to reproduce:
1. Open the Knowledge app
2. Create an article with two child articles
3. Add one of the two children to your favorites with the star icon
4. Open another article that is not under that parent
5. Fold the parent article in the sidebar, then refresh the page
6. Expand the parent article

=> only the favorited child is shown under the parent, the other child is missing

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

Forward-Port-Of: odoo/enterprise#118804

**Steps to reproduce:**
- Install the `l10n_it_edi` module and switch to an IT Company.
- Create and confirm an invoice for a non-Italian customer.
- Send the invoice, making sure that only `by Email` is enabled.
- Attempt to send the invoice again.

**Issue:**
- In `18.0`, the XML file is not generated when re-sending an invoice that 
was previously sent only by email.

- Starting from `19.0`, attempting to `Send to Tax Agency` raises an error:
`UnboundLocalError: cannot access local variable 'attachment_name' where it is not associated with a value`

**Root cause:**
At [1], `_get_alerts` method does not check whether the invoice was previously 
sent only by email. As a result, the warning banner is not displayed, and 
allows the user to `Send to Tax Agency`.

**Fix:**
Restore the expected behavior by preventing `Send to Tax Agency` when 
the invoice was previously sent only by email. Instead, display the 
appropriate warning message instructing the user to delete the 
PDF attachment before sending to the Tax Agency, matching the 
behavior in `17.0` (confirmed with PO).

[1]:
https://github.com/odoo/odoo/blob/c0d8d36481e106f0209521bbb127cb3b1ad1059a/addons/l10n_it_edi/models/account_move_send.py#L27-L33

opw-6293519

Forward-Port-Of: odoo/odoo#269547

`sync_participants` calls `action_set_unlink` on every participant whose record is no longer in the campaign domain, and `action_set_unlink` writes "Record deleted" on each scheduled trace. The removed bucket also contains records that still exist but no longer match the campaign filter, so the cancelled trace dialog shows "Record deleted" even when the record was only filtered out.

In `sync_participants`, the to_remove participants are split between those whose record still exists in the database (filtered out by the campaign domain) and those whose record was actually deleted. `action_set_unlink` accepts an optional `trace_message` argument, defaulting to "Record deleted", and the filtered-out batch passes "Record no longer matches campaign filter" so the cancelled trace dialog reflects the real cause.

Steps to reproduce:
1. Install Marketing Automation and CRM.
2. Open Marketing Automation, create a campaign on Lead with filter Stage = New.
3. Add a begin activity to the workflow.
4. Open CRM, create a Lead in the New stage.
5. Back in the campaign, click Generate Participants.
6. In the CRM pipeline, drag the Lead from New to Qualified.
7. Back in the campaign, click Generate Participants again.
8. Open the Participants smart button, click the participant for the moved Lead.
9. Click the cancelled activity in the workflow timeline.

=> The activity dialog shows "Error message: Record deleted" although the Lead still exists.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6251264)
opw-6251264

Forward-Port-Of: odoo/enterprise#118692

Currently, an error occurs when a user removes the payslip date.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and remove the `start` or `end` period.

**Error 1:**
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

**Error2:**
`AttributeError: 'bool' object has no attribute 'month'`

When a user removes the start or end date of a payslip, the system computes the Average Daily Wage. 
Based on the payslip dates, it finds the previous year's payslips [1]. If the start or end date is not set, 
it raises an error [2].
For the second error, when computing whether to include EOY pay, it compares the company's EOY 
pay date with the end date's month. If the end date is not set, accessing its month raises an error [3].

This commit ensures that when retrieving previous-year payslips, if the start or end date is not set, 
it returns an empty payslip recordset. It also ensures that when computing whether to include EOY 
pay, if the end date is not set, `include_eoy_pay` is set to `False`.

[1]: https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L124

[2]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L209-L215

[3]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L141

Forward-Port-Of: odoo/enterprise#123135
Forward-Port-Of: odoo/enterprise#120586

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

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

Forward-Port-Of: odoo/enterprise#120590
Forward-Port-Of: odoo/enterprise#118937

similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and path@test.com)
3) Generate offer and sign with all the required signer. 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as john@example.com).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as path@test.com)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

**opw-6280170**

Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).

The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.

```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
    setStart@[native code]
    createEditorSelection@.../web.assets_web.min.js:12239:15
    getSelectionData@.../web.assets_web.min.js:12242:145
    updateActiveSelection@.../web.assets_web.min.js:12230:92
    @.../web.assets_web.min.js:12218:873
    handler@.../web.assets_web.min.js:14366:121
```

Steps to reproduce:

1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
   Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
   so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.

Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.

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