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

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

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

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

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

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