When a stock move's UoM differs from the product template's UoM, the report aggregation incorrectly shows data for both UoMs of stock move.quantity on the same graph. All moves should be normalized to the UoM of the product for which we are viewing the forecast.

We can do this with:

`m.quantity * move_uom.factor / pt_uom.factor AS quantity`

If the UoMs of the stock move and the product template are identical, as is the case most of the time, this simply multiplies by one, and the query behaves exactly as it did before. But if the units are distinct, the move UoM is converted into
the product template UoM so that the data for stock move quantity is normalized to one shared unit across the entire forecast graph.

**E.g.**:

m.quantity == 500g
m.UoM == g
m.UoM.factor == 1
pt.UoM == kg
pt.UoM.factor == 1000

500g * 1 / 1000 ==> .5kg

**Steps to Reproduce on Runbot**:
1. Create a product which uses kg and g. 
2. Confirm and Validate a receipt for this product (10 kg for example). 
3. Confirm a second receipt for this product in the same UoM kg. 
4. Confirm and Validate a delivery for this product with UoM g (500 g for example).
5. View the forecasted graph for the product, and you will see that the y axis is scaled on grams ~500, and the current / future stock moves in the report are still scaled based on kg. 

opw-6234066

Forward-Port-Of: odoo/odoo#266811

### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Currently, when printing a request for quotation the incoterm informations are not present.

Steps to reproduce:
-------------------
* Create a new quotation
* Add basic required information
* Open tab "Other info" and fill incoterm field(s)
* Save (don't confirm)
* Print RFQ pdf report
> Observation: The incoterm values are not being printed

Why the fix:
------------
If we look at the html version of that report we can see those information are present before the logo section.

This issue was introduced by the following commit: https://github.com/odoo/odoo/commit/bba2fc505f5d0b4770eacc6877155b1aeda6d772

As we can see the incoterm informations are positioned after the `layout_document_title`
https://github.com/odoo/odoo/blob/a7de246efa8241c49196be0e0477abd086bf9e63/addons/purchase_stock/report/purchase_report_templates.xml#L44-L55

After the mentioned commit the `layout_document_title` is defined before the external layout. So when the report is rendered the incoterm bloc is positioned before the external layout as well which explains why it can be seen in the html and not the pdf.

This fix changes the xpath to make it corresponds to the same placement as it was prior to the issue. The class `page` was chosen in this case as the `layout_document_title` block was before the page class as well and all the blocks that were in between `layout_document_title` and `page` previously are now also before the external layout.


HTML:
<img width="1718" height="867" alt="image" src="https://github.com/user-attachments/assets/0b2a04ec-5f0e-4915-8e57-e511a1cd2d8c" />

PDF:
<img width="1677" height="870" alt="image" src="https://github.com/user-attachments/assets/06e94ea4-6ce6-48ed-85db-c672137877c2" />

After fix:
<img width="1917" height="1002" alt="image" src="https://github.com/user-attachments/assets/158e66a1-83ea-4122-8daa-f90e9aa537d5" />



opw-6211465

[FIX] point_of_sale, pos_viva_com: automatic receipt printing
3 Fixes for the app-to-app integration of Viva

1. Under the normal flow the `OrderPaymentValidation` does the payment
   validation and post validation operations (such as receipt printing or
   preparation prints). Then it launches the `FeedbackScreen` with the
   validation promise on the `waitFor` prop.

   The `pos_viva_com` app-2-app integration does the payment validation on
   the backend on the callback endpoint. Then it redirects the user
   directly on the `FeedbackScreen` skipping the normal validation and post
   validation operations. This means that receipts and preparation prints
   do not get processed.

   This PR adds a check on the `FeedbackScreen` to see whether there is
   anything set on the `waitFor` prop. If the prop is undefined, we can
   expect that the screen was mounted outside the normal flow, so we run
   the post validation operations manually.

---

2. Using the fast payment method with Viva would use
   `order.addPaymentLine` instead of the overloaded
   `payment_screen.addNewPaymentLine`. So the integration pop up which
   is defined in the `payment_screen` would never fire.

   Now I've added a check on `validateOrder` to detect whether we're about
   to use a `fastPaymentMethod`, in which case it will apply the same
   behaviour as the override of the `payment_screen.addNewPaymentLine`

---

3. Added a patch for `reloadData` which will remove the answer for the
   Viva wallet pop up from local storage in case users change their minds
   or made a mistake

Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297)

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

When transferring an order to a table that already has an open order, identical products are merged into a single line. If both orders were already sent to the kitchen printer, the merged line was incorrectly marked as new and had to be sent again.

Steps to reproduce:
-------------------
* Open table 1, add product A (2 units) and product B, send to kitchen
* Open table 2, add product A (3 units) and product C, send to kitchen
* On table 2, transfer/merge the order to table 1

> Observation:
product A shows 2 units as new and must be sent to the kitchen printer again, although all quantities were already sent.

Why the fix:
------------
When merging preparation history for identical lines, handlePreparationHistory overwrote the destination sent quantity with the source one instead of summing both. The kitchen diff then treated the missing quantity as new changes.

A unit test will be added in 18.3.

opw-6246470

Forward-Port-Of: odoo/odoo#271828
Forward-Port-Of: odoo/odoo#267915

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

Forward-Port-Of: odoo/odoo#272198
Forward-Port-Of: odoo/odoo#268505

Problem
----------------------
When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect.

Reason
-------------------
The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation.

Solution
-------------------
The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income.

task-6237717

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#116890

Overview
------

When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X.

How to reproduce
------

1. Create a new mailing for a target model X (e.g. `mailing.contact`)
2. Set a content for that mailing (you can choose from the existing themes)
3. Set that mailing as a favorite (using the favorite star button)
4. Create a new mailing for another target model Y.
5. Redo steps 2. and 3.
6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview)
7. Change the target model to Y.

Expected Behavior
------

Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y.

Current Behavior
------

The title of the template is changed into the one of Y however the preview remains the one of mailing X.

Cause of The Issue
------

After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value.

Task-6332946



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

Forward-Port-Of: odoo/odoo#272065

*: website, website_mass_mailing

__Problem__
In some cases, popup snippets can be dropped inside another popup.
This shouldn't be possible. Moreover, it produces the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`.

This can happen in multiple scenarios:
- After saving a custom snippet, the snippets are reloaded but
  `disableUndroppableSnippets` is not called again, although the
  snippets should be filtered again.
- `NewsletterPopupPlugin` registers `.o_newsletter_popup` in the
  `so_snippet_addition_selector` resource, bypassing the more
  restrictive `dropzone_selector` of `PopupOptionPlugin`.
- Popups are not disabled when the cookie bar is open because we don't
  take `excludeAncestor` into account in `DisableSnippetsPlugin`.

__Fix__
- Trigger an event whenever the snippets are loaded and call
  `disableUndroppableSnippets` when it is.
- Remove the redundant `NewsletterPopupPlugin`.
- Filter `dropAreaEls` with `excludeAncestor` in `DisableSnippetsPlugin`.

Forward-Port-Of: odoo/odoo#271635
Forward-Port-Of: odoo/odoo#269864

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/odoo#269615
Forward-Port-Of: odoo/odoo#268527

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/enterprise#120300
Forward-Port-Of: odoo/enterprise#119530

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#268273

**Step to Reproduce:**

1. Open the POS.
2. Add any product to the order.
3. Proceed to the payment screen and select `Pine Labs` as the payment method.
4. Observe that the Pine Labs terminal does not respond and no payment popup appears on the device.
5. Wait until the payment request is cancelled (either manually or due to timeout).
6. Click the `Force Cancel` button.
7. Observe that the POS throws a traceback.

**Video:**
https://drive.google.com/file/d/1A3QPdby-J12IWgOX_SfCLrauQ_QnbqvG/view

**Issue:**

When a Pine Labs payment request is cancelled (either through a cancel request or by timeout), clicking the `Force Cancel` button results in a traceback in
 the POS.

**Reason:**

During the cancellation flow, the payment line status is updated to `retry` so that the transaction can be marked as cancelled and retried if necessary.

Later, when the user clicks `Force Cancel`, `_paymentCancelRequestHandler()` attempts to retrieve the pending Pine Labs payment line using:

```javascript
const line = this.pendingPineLabsPaymentLine();
```

However, `pendingPineLabsPaymentLine()` only returns payment lines whose status is not `retry`, as defined here:

https://github.com/odoo/odoo/blob/19.0/addons/point_of_sale/static/src/app/services/pos_store.js#L1820

Since the payment line was already transitioned to the `retry` state during the cancellation flow, no `payment line` is found and `line` becomes `undefined`.

The handler subsequently attempts to update the status of this `undefined` `payment line`, resulting in the traceback when `Force Cancel` is executed.

**Solution:**

Add a condition in `_paymentCancelRequestHandler()` to verify that a payment line is available before attempting to update its status.

If no payment line is found, it indicates that the payment line has already been
 moved to the `retry` state during a previous cancellation attempt. In such
cases we clear `pollingTimeout`, `inactivityTimeout` and reset `this.payment_stopped` to `false`.

This prevents the traceback while ensuring that the `Force Cancel` flow properly cleans up the pending payment state.

opw-6297135

Forward-Port-Of: odoo/odoo#271397
Forward-Port-Of: odoo/odoo#271241

Steps to reproduce:
* Install `l10n_mx_edi` (or `l10n_sa_edi`).
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

Observed behavior:
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

Cause:
* `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`.  However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated.

Fix:
* Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain.
* Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call.

This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic.

opw-6228268

Forward-Port-Of: odoo/odoo#271489

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#271795
Forward-Port-Of: odoo/odoo#269743

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

**Issue 1:**

Step to reproduce:
- Type ':wave' to open suggestion list
- Now click on any emoji from the suggestion list

Description of the issue:
- The selected emoji gets inserted, but the `searchNode` `:wave` does not get removed and remains beside the inserted emoji

Cause:
- When the user clicks an emoji from the suggestion list, focus shifts to the suggestion list item. As a result, `selection.extend()` is unable to properly select the searchNode in the editable area. Because the `searchNode` is not selected, `deleteSelection()` fails to remove it before inserting the emoji.

Solution:
- Added the `user-select-none` class to the suggestion list to prevent selection/focus shift on emoji click, ensuring the searchNode is properly selected and replaced by the selected emoji


**Issue 2:**

Steps to reproduce:

- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:

- When using the SwiftKey keyboard, pressing Backspace after an emoji can result in an incorrect cursor position.

Cause:
- When Backspace is pressed, a selection snapshot is cached during the `keydown` event.
- Later, `deleteBackward` converts the emoji back to its corresponding expression (:p) by triggering an undo operation, but the cached selection does not get updated. As a result, the previously cached selection is reused, causing the cursor to be placed incorrectly.

Solution:

- After performing the undo, update the cached selection to match the new cursor position.
- This ensures that the latest selection is used instead of the outdated selection captured during `keydown`.

**Issue 3:**

Steps to reproduce:
- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:
- Pressing Backspace on an emoji does not revert it to its matching expression (`:p`).

Cause:
- On mobile devices, `event.key` can be undefined in keydown. As a result, `deleteBackward` is triggered through the `beforeinput` event, which correctly reverts the emoji to its matching expression. However, after that, the `input` event is triggered and converts the expression back into the emoji again, making it appear as if the emoji was not reverted.

Solution:
- When the event type is `deleteContentBackward`, skip converting the expression back into an emoji and return early.


task-6201173

__To reproduce__
1. Drop a popup on the website.
2. Click twice rapidly on the popup show/hide toggle in the sidebar.
=> The popup visibility will be in an inconsistent state compared
   to the toggle's eye icon.

__Reason__
Bootstrap ignores any call to show/hide if the popup is still
transitioning.

__Fix__
- Set `_isTransitioning` to `false` to trick Bootstrap into firing the
event regardless of its current state.
- When hide/show are triggered in quick succession, the modal can enter an
inconsistent state with `.show` class but `display: none` style (hide removes
`.show` immediately, show restores it with `display: block`, then hide applies
`display: none` after animation). Dispatching `transitionend` event before
resetting `_isTransitioning` ensures Bootstrap completes its state transitions.

__Note__
This commit also fixes `custom_popup_snippet`, which fails
non-deterministically with the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`

This error occurs when trying to add a popup inside another popup
that never closes due to this bug.

runbot-939039

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring effect both read `mountedAndLoaded` as a dependency and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write pair `[isLoaded=true, mountedAndLoaded=false]`; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window, it drives `mountedAndLoaded` back to false while `isLoaded` stays true. The settling patch then computes the very `[true, false]` pair that was already recorded, so the effect never re-runs: `mountedAndLoaded` is stranded at false and no message is ever rendered.

Depend on a monotonic `resetCount` bumped by `reset()` instead of on `mountedAndLoaded` itself. It is never written by the effect, so the recorded dependencies can no longer match the current ones after a reset and the effect always re-runs to re-sync `mountedAndLoaded` with `isLoaded`. `reset()` keeps clearing `mountedAndLoaded` as before (the false dip is needed for the reload scroll handshake), so the behaviour is otherwise unchanged.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#272281