### Description of the issue/feature this PR addresses:
Fixes an issue where timesheets lose their invoice reference when reversing and re-creating an invoice via a credit note.

### Current behavior before PR:
When reversing an invoice tied to timesheets and creating a replacement via a credit note, the timesheets linked to the original invoice have their timesheet_invoice_id cleared. Because the modify_moves function builds the replacement invoice directly via copy_data()/create(), it bypasses the normal sale order invoicing flow. As a result, the unbilled timesheets are left permanently unlinked from the newly created invoice, leaving the new invoice with no reference to the timesheets linked to the original sale order.

### Desired behavior after PR is merged:
When a replacement invoice is created, each timesheet is properly relinked to the corresponding line on the new invoice. This linkage matches on the sale order line (so_line) rather than line position, ensuring accuracy since line order and count are not guaranteed to be preserved between the original and modified invoices.

opw-6449995

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

Forward-Port-Of: odoo/odoo#285232
Forward-Port-Of: odoo/odoo#283104

Before this commit, a unit test suite could go silent between two test files, and `browser_js` then waited out its whole timeout before failing with:

    [ERROR] TypeError: Failed to fetch
        at orm (web.assets_unit_tests.min.js)
    FAIL: WebSuite.test_unit_desktop
    AssertionError: Script timeout exceeded

This happens because `fetchDependencies` gives every addon a `Deferred` that only the success handler of the batched `all_dependencies` call resolves, and a loaded runbot host answers that call with `RuntimeError: can't start new thread`. Nothing then settles those deferreds, so the `Promise.all` waiting on them never returns, `stop()` is never called, and the browser holds the build until the timeout.

This commit rejects the deferreds of a failed batch and reports an error escaping `runTests` on the console, so the build fails on the fetch error instead of running out its timeout.

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

Forward-Port-Of: odoo/odoo#285834
Forward-Port-Of: odoo/odoo#284980

The `move_line_ids` field has been a computed Many2many field since its introduction. Starting from V19.0, it was changed to a regular Many2many field [Here](https://github.com/odoo/odoo/pull/171743).

The current field definition incorrectly passes the second positional argument as the [relation](https://github.com/odoo/odoo/blob/19.0/odoo/orm/fields_relational.py#L1255) table name. Since the relation name starts with an uppercase character, as the table store as "Products" In addition, the relation table is mistkanley defined (not sure) instead of letting the ORM generate the relation table.

Update the field definition to use the correct field parameters and let the ORM handle the relation table creation.

Issue:
- The standard convention for automatically generated Many2many relation tables is to use a `_rel` suffix.
- Some databases already have a custom relation table with the same table name Products as the one explicitly defined by this field. When upgrading such databases, the ORM attempts to create the conflicting relation table, which can cause the migration to fail.

This change avoids the conflict and makes the field definition consistent with the expected ORM behavior.

current behaviour
```
labo_19_2=# \d "Products"
                         Table "public.Products"
            Column            |  Type   | Collation | Nullable | Default 
------------------------------+---------+-----------+----------+---------
 stock_package_destination_id | integer |           | not null | 
 stock_move_line_id           | integer |           | not null | 
Indexes:
    "Products_pkey" PRIMARY KEY, btree (stock_package_destination_id, stock_move_line_id)
    "Products_stock_move_line_id_stock_package_destination_id_idx" btree (stock_move_line_id, stock_package_destination_id)
Foreign-key constraints:
    "Products_stock_move_line_id_fkey" FOREIGN KEY (stock_move_line_id) REFERENCES stock_move_line(id) ON DELETE CASCADE
    "Products_stock_package_destination_id_fkey" FOREIGN KEY (stock_package_destination_id) REFERENCES stock_package_destination(id) ON DELETE CASCADE
```
After fix 
```
labo_19_2=# \d stock_move_line_stock_package_destination_rel
      Table "public.stock_move_line_stock_package_destination_rel"
            Column            |  Type   | Collation | Nullable | Default 
------------------------------+---------+-----------+----------+---------
 stock_package_destination_id | integer |           | not null | 
 stock_move_line_id           | integer |           | not null | 
Indexes:
    "stock_move_line_stock_package_destination_rel_pkey" PRIMARY KEY, btree (stock_package_destination_id, stock_move_line_id)
    "stock_move_line_stock_package_stock_move_line_id_stock_pack_idx" btree (stock_move_line_id, stock_package_destination_id)
Foreign-key constraints:
    "stock_move_line_stock_package_destinati_stock_move_line_id_fkey" FOREIGN KEY (stock_move_line_id) REFERENCES stock_move_line(id) ON DELETE CASCADE
    "stock_move_line_stock_package_stock_package_destination_id_fkey" FOREIGN KEY (stock_package_destination_id) REFERENCES stock_package_destination(id) ON DELETE CASCADE
```

Ticket: 6485470

Upgrade pr :-https://github.com/odoo/upgrade/pull/11189
Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Issue:
------------------------------------------
Clicking the `+` button on a receipt in Barcode for a lot/serial tracked
product gives traceback instead of opening the lot/serial generation dialog.

Steps to reproduce:
------------------------------------------
 1. Install `stock_barcode`.
 2. Create product P1 with serial tracking.
 3. Create receipt for P1.
 4. Go to barcode and click on `+` button to generate serial number.
 5. Traceback: `Cannot read properties of undefined (reading 'getRecord')`

Cause of the issue:
------------------------------------------
`LineComponent.openDialog()` was trying to access `this.cache.getRecord(...)`,
but `LineComponent` does not define a cache property. This issue was introduced
by PR https://github.com/odoo/enterprise/pull/129521, which fixed a similar traceback when generating serial/lot
numbers from Barcode for manufacturing orders.

Solution:
------------------------------------------
Use `this.env.model.cache.getRecord(...)` when resolving the move before opening
the dialog. This avoids the undefined access and allows the serial/lot
generation dialog to open normally.

In the bank reconciliation widget, a reconciled transaction
matched with a bill and a loss exchange entry no longer displays
the bill reference next to the reconciled line.

Steps to reproduce:

- Have company currency USD and foreign currency EUR
- Create a vendor bill in foreign currency (100 EUR, rate 1 USD = 1 EUR)
- Create a bank transaction in the foreign currency for less than the
  bill total, at a rate making the amount higher in company currency
  (90 EUR, 108 USD at 1 EUR = 1.2 USD)
- Open the bank reconciliation widget, reconcile transaction and bill
- Unfold the reconciled transaction

Issue:

A bill reference is missing

Analysis:

The exchange difference line is reconciled with the transaction line.
Being reconciled with two lines (bill and exch), the widget relies
on `*_reconciled_lines_excluding_exchange_diff` to show the fields.
However, `count_reconciled_lines_excluding_exchange_diff`
has been defined as boolean instead of int, faulting the comparison.

opw-6479015

Forward-Port-Of: odoo/odoo#283855

## Steps to reproduce:

- Create another warehouse
- Create a product with a variant, like Color, values black and white
- Track the product, add a qty on hand of 50 on the black product
- Go to the sales app, make a quotation of 50 for the black product
- Confirm the quotation
- Go to the PoS, click on the product, check the available qty in the popup
- It is still 50, even though the forecasted is correct at 0

## Why the fix:

Having the actual free qty was added in this commit 682bc82 to be able to check the qty that was really free instead of the available qty. This means that we subtract the reserved_qty from the qty_available to get the free_qty.

The variant popup was forgotten in this commit, so it was still displaying the qty_available. This is why there was a difference in the qty if we press the product normally or if we long press it, because the variant popup was forgotten in said commit.

opw-6382845

Forward-Port-Of: odoo/odoo#284321
Forward-Port-Of: odoo/odoo#280330

### Problem
- Fixed salary payslips were not being prorated correctly. The 50% rule threshold was compared against
  `hours_per_week` (single week) instead of 50% of the theoretical hours for the payslip period.
  This led to incorrect salary deductions in all cases and the wrong computation path being taken when less than 
  50% of the month was worked.

### Solution
- Fix `_l10n_be_has_enough_paid_hours` to compare paid hours against 
  50% of theoretical hours instead of `hours_per_week` (which are calculated for the employee's `working schedule`)

### How it works
- For fixed salary (`wage_type = 'monthly'`), the quarterly hourly rule 
  is applied as follows:

- **Hourly rate** = `fixed_salary × 3 / 13 / theoretical_hours`
- **50% rule**:
  - If more than 50% of theoretical hours were worked → deduct absences 
    from fixed wage
  - If less than 50% of theoretical hours were worked → pay only the 
    hours worked

For variable salary (`wage_type = 'hourly'`), the employee is simply 
paid for the number of hours worked during the period.

Task-6260378

Forward-Port-Of: odoo/enterprise#126600

Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the write:

    [verifySteps] expected the following steps
    > Expected: [
      "web_save",
    ]
    > Received: []

This happens because a tap held longer than `LONG_TAP_DELAY` counts as a long press, and `_pointerUp` then dispatches no click at all. That delay spans the synthetic pointerdown and pointerup of a single `click()`, so the work a listener does during the press counts towards that delay: tapping save blurs the html field, which converts the whole editor content to inline styles, and under the load of a runbot build that conversion alone takes longer than the delay.

One solution could have been to raise `LONG_TAP_DELAY`, but a listener slower than the new value suppresses the click again.

This commit counts a tap as long only when the test releases the pointer itself, with `pointerUp`, so the work a listener does during a `click()` no longer suppresses the click.

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

Forward-Port-Of: odoo/odoo#285640
Forward-Port-Of: odoo/odoo#284971

Steps to reproduce:
- Restaurant config with two POS devices on the same session
- Device A: open a table, add two products, press Order (the order is synced as a draft, its lines get server ids)
- Device A: remove both lines, without syncing
- Device B: touch the same order, so device A re-reads it from the server through the synchronisation websocket
- Device A: pay and validate the order

Issue:
The order is saved as paid, with its total and its payment, but without any orderline. The lines are deleted on the server: odoo.models.unlink: deleted pos.order.line records with IDs: [...]

Cause:
Removing an orderline queues an unlink command in
models.commands['pos.order'].unlink['lines_<order id>'] (delete_ in related_models.js). That command is only discarded by clearCommands(), which syncAllOrders() calls after a successful sync, so it stays pending in between.

Any read of the order in that window puts the line back: a deleted record counts as missing in missingRecursive(), so it is fetched again and loadData() re-creates it with its server id.

serialize() then emits both the update of the live line and the still pending unlink, and sync_from_ui writes
lines: [[1, id, {...}], [3, id]]. The ORM applies commands in order, and pos.order.line.order_id is ondelete='cascade', so Command.UNLINK deletes the line right after writing it.

Fix:
Skip a removal command when the record is still linked to the parent at serialization time. A record cannot be both linked and removed in the same payload, so the pending command is stale and dropping it keeps the local state. Genuine removals, where the record is no longer linked, are still sent.

opw-6401146

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

Forward-Port-Of: odoo/odoo#285427
Forward-Port-Of: odoo/odoo#284695

### Steps to reproduce:

- In the settings: Enable Storage Locations
- Create a customer location "Customer stock" with "Customers" as its parent location
- Create a delivery operation type "Deliver Super Customer" and set its default destination location to "Customer stock"
- Go to Inventory > Overview > Deliver Super Customer > New
- Set a contact on the transfer
#### > The destination location switches from "Customer stock" to "Customers"

### Cause of the issue:

The `location_dest_id` of `stock.picking` depends on its `partner_id`. So that changing the partner recomputes the locations of the transfer. However, as soon as the destination of the operation type has a `customer` usage, the `property_stock_customer` of the contact replaces it unconditionally:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L949-L963 
However, the `property_stock_customer` falls  back to an `ir.default` pointing at the default `Customers` location when nothing is set on the contact:
https://github.com/odoo/odoo/blob/1c40fab04b71def8f3645c4c4bb0c1441057f307/addons/stock/data/stock_data.xml#L71-L72vs

The override comes from 8a0775aa1dd9, which replaced an `elif` fallback on the contact by an "unconditional" substitution as this fallback had become unreachable once `default_location_src_id` and `default_location_dest_id` were made required:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L34-L41

opw-6421090

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

Forward-Port-Of: odoo/odoo#284873
Forward-Port-Of: odoo/odoo#280016

### Steps to reproduce
**Issue 1:**
* Create a table inside another table (e.g. `/table`).
* Resize the last cell of the inner table beyond the outer `td` boundary.
* Then try to resize the outer table `td` containing the inner table.
* The outer table `td` can no longer be resized.

**Issue 2:**
- Create a table in the editor
- Inside any cell, create a nested table
- Resize the nested table by dragging its last column to the left to
  give it a fixed width
- Resize the outer column that contains the nested table to the left
- Observe that the nested table overflows its parent cell

**Issue 3:**

- Create a table in the editor
- Inside any cell, create a nested table
- Resize the nested table columns to give it a fixed width
- Double-click the outer column border to reset its width
- Observe that the nested table overflows its parent cell

### Purpose of this PR

Prevent resizable elements from growing beyond the bounds of their nearest resizable ancestor.

This fixes resize behavior for nested resizable structures such as:

* tables inside tables
* text columns inside tables
* tables inside text columns

The resize logic now clamps width expansion once the nearest resizable ancestor boundary is reached.
- When resizing an outer table column that contains a fixed-width nested table, the outer column could be shrunk below the nested table's width, causing the nested table to overflow its parent cell.
- The fix computes an effective minimum size per column by inspecting any fixed-width nested tables in that column's cells before the resize begins. This effective minimum size is passed through the resize_target_processors resource so ResizePlugin remains generic.
- When resetting an outer column width, any fixed-width nested table inside the affected cells is also reset so it adapts naturally to the new outer column width instead of overflowing its parent cell.

task-6215674

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

Forward-Port-Of: odoo/odoo#264633

The withholding tax exemption for the employer intervention in home-work transportation costs (500 EUR/year - 41.70 EUR/month for income year 2026) was estimated from contract fields (car_atn, private_car_employee_kilometer) instead of the amounts actually taxed on the payslip. As a consequence:

- The fuel card for daily commute was fully taxed: the employee never received the exemption they are legally entitled to.
- The private car reimbursement was paid net, never added to the taxable base, yet it still granted the exemption on the yearly taxable: a double benefit.
- A bike allowance paid above the exempt rate per km (0.37 EUR/km in 2026) was never taxed.

The exemption is now computed from a new TRANSPORTATION_BASE salary rule category accumulating the taxable transportation amounts of the month:

- ATN.CAR and FUEL_CARD_COMMUTE (already taxed) are tagged with the category.
- New hidden rules CAR.PRIV.TAX and CYCLE.TAX fictively add the private car reimbursement and the above-rate bike excess to the withholding base, after ONSS and before the gross totals, while the reimbursements themselves remain paid net.
- TRANSPORT_TAX_DED becomes -min(yearly taxable, yearly threshold, 12 x monthly transportation base), including the transport lines of already validated payslips of the same month so that non-periodic (regularisation) payslips preserve the monthly totals. The termination fees variant uses the category without x12, its base being annual.

The obsolete helper _get_be_withholding_taxes_transport_deduction is removed, and the affected payslip validation expectations are updated to the corrected amounts.

task-6388103

Forward-Port-Of: odoo/enterprise#124644

## Merge method
squash

---

## Problem

The DIOT report (`account_report_diot.xml`) uses inline `name@es_419` translations for Spanish (Latin America) column headers. However, the translations were inconsistently applied: columns at 16% had them, while the equivalent 8% columns and several others were left without Spanish translations.

**Columns missing `name@es_419` (before this fix):**

| `id` | English name | Added es_419 |
|---|---|---|
| `diot_report_paid_8_n_wnc` | Paid 8 % Northern | Pagado al 8% Norte |
| `diot_report_paid_8_n_r` | Refunds 8 % Northern | Devoluciones 8% Norte |
| `diot_report_paid_8_s_wnc` | Paid 8 % Southern | Pagado al 8% Sur |
| `diot_report_paid_8_s_r` | Refunds 8 % Southern | Devoluciones 8% Sur |
| `diot_report_paid_16_r` | Refunds 16% | Devoluciones 16% |
| `diot_report_paid_16_imp_r` | Refunds Importation 16% | Devoluciones Importación 16% |
| `diot_report_paid_16_imp_int_wnc` | Intangible Imports 16% | Importaciones Intangibles 16% |
| `diot_report_paid_16_imp_int_r` | Refunds Intangible Imports 16% | Devoluciones Importaciones Intangibles 16% |
| `diot_report_paid_8_n` | Paid 8 % N. - Creditable | Pagado al 8% Norte - Acreditable |
| `diot_report_paid_8_s` | Paid 8 % S. - Creditable | Pagado al 8% Sur - Acreditable |
| `diot_report_paid_16` | Paid 16% - Creditable | Pagado al 16% - Acreditable |
| `diot_report_paid_16_imp` | Importation 16% - Creditable | Importación 16% - Acreditable |
| `diot_report_paid_16_imp_int` | Intangible Imports 16% - Creditable | Importaciones Intangibles 16% - Acreditable |
| `diot_report_paid_8_n_nc` | Paid 8 % N. - Non-Creditable | Pagado al 8% Norte - No acreditable |
| `diot_report_paid_8_s_nc` | Paid 8 % S. - Non-Creditable | Pagado al 8% Sur - No acreditable |
| `diot_report_paid_16_imp_nc` | Importation 16% - Non-Creditable | Importación 16% - No acreditable |
| `diot_report_paid_16_imp_int_nc` | Intangible Imports 16% - Non-Creditable | Importaciones Intangibles 16% - No acreditable |
| `diot_report_exempt_imp` | Exempt Imports | Importaciones Exentas |
| `diot_report_no_obj` | No Tax Object | No Objeto de Impuesto |

## Why this matters

Mexican Odoo instances run with `es_419` locale. Without these inline translations, column headers in the DIOT report display in English for Mexican accountants, even though the equivalent 16% columns already had Spanish translations. This creates an inconsistent bilingual UI on the same report.

## Fix

Adds `<field name="name@es_419">` entries to all column records that were missing them, following the same pattern already used by `diot_report_paid_16_wnc`, `diot_report_paid_16_nc`, `diot_report_withheld`, `diot_report_exempt`, and `diot_report_paid_0`.

## Files changed

- `addons/l10n_mx/data/account_report_diot.xml`

Issue
-----
When adding all of the catalog's suggestions at once, the uom specified on the product's vendor lines is not respected.

Steps to reproduce
-----
- Create a product
	- Add a vendor line in a different uom
- Create a past outgoing shipment of 100 of the product
- Create a PO (same vendor as vendor line)
	- Open the Catalog
	- Click "Add All" in the suggestion section on the left
- Go back to the PO

> The product is in units instead of the different uom

Cause
-----
Clicking the button calls `action_purchase_order_suggest` in Python directly

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/models/purchase_order.py#L131-L134

whereas clicking on a product will go through `addProduct` in JS

https://github.com/odoo/odoo/blob/3aec1c317aad547b1ad0c85a21cc53f735c5cbfd/addons/purchase_stock/static/src/product_catalog/record/kanban_record.js#L20-L28

Which leads to `_update_order_line_info` where the purchase line is created

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order.py#L1322-L1328

The uom is then retrieved in the create call through `_suggest_quantity`

https://github.com/odoo/odoo/blob/f59783d43f891fea14d03f67d7c017d7ffbbe5a7/addons/purchase/models/purchase_order_line.py#L547-L549

Other issue
-----
The quantity of the product also doesn't match the suggestion since the product `suggested_qty` is in the product's uom and not the vendor ones.

-----
Ticket:
opw-6417665

Forward-Port-Of: odoo/odoo#284841
Forward-Port-Of: odoo/odoo#280934

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

`weeknumber` takes a `first_week_day` override, documented as `(0 = Monday, ..., 6 = Sunday). If None, derived from the locale.`, but tests it with `if not first_week_day`, so Monday (`0`) is discarded and the locale's own day is used.

`resource` passes `int(get_lang(self.env).week_start) - 1`, which is exactly `0` for Monday, at three call sites. #259600 added the parameter for the opposite case, a Monday locale with a Sunday-start user, and that direction works; this one never has.

**Current behavior before PR:**

With `en_US` (first day Sunday) and week start set to Monday, `resource_resource.py:299` builds `week_start_date` from Monday while `:303` buckets by Sunday. Monday 2026-08-24 to Sunday 2026-08-30 comes back as W35 for six days and W36 for the Sunday, so one week's hours are split across two buckets and the `hours_per_week` cap lands on the wrong days.

**Desired behavior after PR is merged:**

The override is honoured and those seven days are all W35.

I checked this with a partition property: every day of a `first_week_day`-aligned week must share one `(year, week)`. Over 9 locales x 7 values of `first_week_day` x 12 years, 275940 combinations, 5 locales failed and every failure was in the `first_week_day=0` bucket. After the change there are none.

I also diffed every output before and after, 315360 combinations of locale, `first_week_day` and date: 4460 rows change, all of them `first_week_day=0` on a non-Monday locale. `None` and values 1 to 6 are byte identical, so the change is contained to the broken case.

Targeting 19.0 because that is the oldest branch carrying the parameter; 17.0 and 18.0 do not have it.

AI-assisted: I used Claude to sweep the parameter space and write the tests.

Forward-Port-Of: odoo/odoo#285706
Forward-Port-Of: odoo/odoo#285508

In Gantt views, for a given focus date, the appropriate time interval is
displayed by finding its start and end date, based on the scale.

For example, if I focus on 18 may 2026 with a month scale, then the
whole month of may is displayed.

The behaviour was as expected in standard code, because all
localisations agree on the beginning of the available scales (day,
month, year).

In custom code, however, some customer requires to see the gantt charts
with a weekly scale. The differences in start of the week based on the
localisations and the inconsistencies of use of localStartOf breaks the
view.

For example, if the localization has the start of the week on a sunday,
and a task on the first column starts on a sunday as well, it will get
assigned to column before (because it considers sunday as the last day
of the previous week). The column before the first column does not
exist, so one empty column is created to put the task in it.

This commit fixes these inconsistencies so that GanttRenderer behaves as
expected with weekly scales, without changing the standard behaviour.

Tests are written to check both that the task is assigned to the proper
localized week (starting on Sunday) and column (1, not 0).

Forward-Port-Of: odoo/enterprise#129408
Forward-Port-Of: odoo/enterprise#118625

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

When creating an employee declaration without selecting an employee, a traceback occurs.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll`` module with demo data
- Switch to Belgian company
- Go to Payroll > Reporting > Individual Accounts > Create a new Individual Account >
  Click on Eligible Employees > Create a new employee declaration without employee > Save

Traceback:
```py
ValueError: Expected singleton: hr.employee()
```

https://github.com/odoo/enterprise/blob/000544c3d5b93e194264e15bb73d9599525106e3/hr_payroll/models/hr_payroll_employee_declaration.py#L71
The ``_compute_version_id()`` method calls ``_get_version()``.
When ``employee_id`` is empty, ``_get_version()`` is invoked on an empty ``hr.employee`` record,
and its ``ensure_one()`` call raises the above traceback at [1].

[1]: https://github.com/odoo/odoo/blob/3c358ae2badad69b125695a97b4a14e8ab77fccd/addons/hr/models/hr_employee.py#L745-L750

Upgrade PR: https://github.com/odoo/upgrade/pull/11026

sentry-7625826444

Forward-Port-Of: odoo/enterprise#125175

Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one:

    odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser:
    Error received after termination: [MEMINFO] tests done (after GC)
    - used: 220535896 - total: 341990868 - limit: 4395630592

Note that the figures themselves are fine (220MB used of a 4.4GB limit): the error is not about memory, only about when the line is logged.

This happens because the runner logs that line after `stop()`, and `stop()` is what reports the suite result: the server settles the test on that report and kills the browser. The final major GC outlasts the report. A passing build escapes because the browser dies within milliseconds; a failing one stays up for the screenshot, long enough for the GC to finish and the line to land after termination.

This commit fixes the issue by moving `stop()` after the final cleanups and their memory log: the [MEMINFO] line is still logged, but before the result report, while the server still waits on the browser.

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

Forward-Port-Of: odoo/odoo#284957

closing the chat with the ai agent on the ai_livechat snippet results in a chatwindow popping up which gives a bad user experience.

Steps to reproduce:
- Log in as Mitchell Admin.
- Go to website.
- Click on edit and choose `Contact & Forms`.
- Add the AI Livechat website snippet.
- From the snippet options, add an AI Agent and choose a livechat team.
  Make sure that Mitchell Admin is configured as an operator for that
  livechat team (livechat channel).
- Click on save.
- Open an incognito tab. Log in as Marc Demo.
- Go to Website.
- Type a message inside the `ASK AI` text area and press enter.
- Wait until you receive a response and then click close.
- A chat window will popup with the messages of the conversation with
  the AI along with a message saying `Visitor has left the channel`.
This happens because `close` button will call `closeConversation`
=> `livechatService.leave()` => `visitor_leave_session` =>
`_close_livechat_session` that posts a message that the visitor has
left the channel.

This commit solves the issue by setting the user who left the channel as the author of the `visitor left chat` message instead of OdooBot.

Steps:
1. Turn on AvaTax for a company (connect it to Avalara).
2. In Settings > General Settings > Invoicing, set the Document Layout to Boxed (Box), just for a clear view.
3. Create a customer invoice:
   - Use the customer with an AvaTax fiscal position and proper address details.
   - Add a product with an AvaTax category.
   - Add a section line (a divider/heading row).
   - Compute Taxes for the AvaTax.
4. Print the invoice as a PDF.
5. Look at the section/divider row. Its cell border does not line up with the other rows. On longer invoices, this can also cause a big blank gap at the bottom of a page.

Cause:
When an invoice is computed by AvaTax, the Taxes column is hidden from the PDF (this is intentional, since AvaTax shows tax differently).

But a different part of the same template decides how wide the section row should be. This part does not know the Taxes column was hidden, so it still counts it. That makes the section row's width wrong by one column, which breaks the table layout in the PDF.

Fix:
Instead of hiding the Taxes column only in one place, fix it at the source: the variable that decides (does this invoice show a Taxes column) now also checks if the invoice is an AvaTax invoice. Every other part of the template that uses this variable (the header, the tax cells, and the section row width) automatically gets the right answer, since they all read from the same place.

Result:
- Section rows on AvaTax invoices now have the correct width.

opw - 6455674

Forward-Port-Of: odoo/enterprise#129097

**Problem:**
Opening a Project Update activity from the activity menu (the clock icon in the systray) lists every project update of every user, instead of the ones carrying the current user's activities.

**Steps to reproduce:**
1. Schedule an overdue activity on a project update
2. Have a colleague create another project update with no activity
3. Click the clock icon in the systray
4. Under "Project Update", click the "Late" count

**Current behavior:**
The list opens unfiltered and shows all project updates, including the ones of other users and the ones carrying no activity at all.

**Expected behavior:**
The list shows only the updates carrying the user's own activities, restricted to the bucket that was clicked.

**Cause of the issue:**
The activity menu never builds a "my activities" domain. `openActivityGroup` in `mail/static/src/core/web/activity_menu.js` narrows the generic act_window it opens purely through context keys — `search_default_filter_activities_my` plus `search_default_activities_overdue` / `_today` / `_upcoming_all` — and the only domain it forwards comes from `_get_activity_groups`, which is limited to `[('active', 'in', [True, False])]`. A `search_default_<name>` key is resolved against a filter of that name in the model's search view, and is silently dropped when no such filter exists. `project.update`'s search view never declared them, so every key the menu sends is discarded and the action opens on an empty domain.

**Fix:**
`project.project` and `project.task` — the addon's two other `mail.activity.mixin` models — already declare this block of invisible activity filters, as does every other model reachable from the activity menu. Declaring them on `project.update` is what makes the menu's context keys resolvable, and keeps the model consistent with the rest of the codebase instead of special-casing `project.update` on the client side.

opw-6416397

Forward-Port-Of: odoo/odoo#281511

### Issue:
A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version

### Cause:
`_get_version` on `hr.employee` falls back to `versions[0]` when no version matches the given date
But if the employee has no versions at all, `versions` is empty and `versions[0]` raises an `IndexError`

### Steps to reproduce:
-  Create a database with `hr_attendance` installed in 18.0
- Upgrade to 19.0

Before the fix, a warning is logged during the upgrade

### Notes:
An employee without any version is a transient state during upgrade
`hr/saas~18.4.1.1/end-migrate.py` backfills a version for every employee still missing one (`current_version_id IS NULL`) once the whole upgrade chain is done
Since it only runs at the very end, an employee can still be found without a version by earlier steps (e.g. modules reloading their demo data), which is when this warning was logged
Confirmed on an upgraded RunBot database that employees without a version before the upgrade do end up with one once fully completed

runbot-241187

Forward-Port-Of: odoo/odoo#284467

Steps to reproduce:
- Enable presets on a restaurant PoS and tick "Amount of Guests" on the preset used for tables
- On device A, open a table and enter the number of guests
- On device B, open the same table

Issue:
Device B pops the guest count numpad again, even though the guest count was already entered on device A.

Cause:
ensureGuestCustomerCount guarded the popup on order.uiState.guestSetted. uiState is only serialized to IndexedDB (SERIALIZED_UI_STATE_PROP, used by serializeForIndexedDB); it is never sent to the server, so the flag is local to one browser and a second device always considers the guest count as not yet asked.

customer_count is synced and could carry that information, but PosStore createNewOrder pre-filled it with the table seats, so it was never 0 for a table order and could not tell "not asked" from "answered".

Fix:
Stop storing the seats default on the record and expose it from getCustomerCount() instead, so customer_count == 0 means "no guest count entered yet". ensureGuestCustomerCount now guards on that synced value, so an order whose guest count was entered on another device is not asked for it again. Every display goes through getCustomerCount(), so the values shown on the Guests button, the receipt and the preparation ticket are unchanged.

opw-6470180

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

Forward-Port-Of: odoo/odoo#285444
Forward-Port-Of: odoo/odoo#283002