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

### Steps to Reproduce:
1. Go to Sales > Configuration > Settings
2. Under Quotations & Orders, enable "Lock Confirmed Sales"
3. Now create a Quotation with 2 products, 1 with attributes and 1 without
4. Confirm the order
5. Hover over the product with attributes and notice that it allows you to to edit, but hovering over the other product does NOT reveal the edit icon

### Issue:
When a user has configured their database to lock sale orders, it should not be possible to edit the products once the order has been confirmed. It currently only happens for products that have attributes. While standard products cannot be edited in a locked state, a missing condition on configurable products allows the button to persist when hovering over the description column. This creates an inconsistent UI state where users appear to have access to modify some of the line items.

### Solution:
To fix this, we updated the `hasConfigurationButton` getter in `sale_product_mixin.js` to evaluate the parent document's locked state. By adding `!this.props.record.model.root.data.locked` to the getter's return logic, the edit button is now globally hidden across all related widgets (such as `sale_label_text` and `sale_product_field`) when the
sales order is locked. This ensures that configurable products properly respect the locked document restrictions just as standard products do. Additionally, this locked condition was applied to the method overrides in the `event_sale` and `event_booth_sale` modules, ensuring that event tickets and booths also hide their configuration buttons on locked orders.Additionally, this locked condition was applied to the method overrides in the event_sale and event_booth_sale modules, ensuring that event tickets and booths also hide their configuration buttons on locked orders.

opw-6512288

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

Issue:
When a user selects a generic appraisal template other than the first one, confirming or resetting the appraisal silently replaces that selection with the first generic template. Filtering appraisals by the originally selected template then fails to return the appraisal.

Steps to reproduce:
* Configure multiple appraisal templates without department restrictions.
* Create an appraisal and select a template other than the first one.
* Confirm the appraisal.
* Filter appraisals by the selected template.

Cause:
`_compute_appraisal_template()` only preserved templates directly linked to the appraisal's department. Generic templates have no department relation, so a valid selected template was discarded whenever the computation was triggered by a state dependent department recomputation. The generic fallback then stored the first template instead.

https://github.com/odoo/enterprise/blob/5c57ccbb13269af28de0a6c7f35454be52424f43/hr_appraisal/models/hr_appraisal.py#L195-L209

Solution:
We need to distinguish the generic default loaded on an unsaved form from a compatible generic template already stored on an appraisal. Preserve the latter across recomputations while retaining department template priority during creation and rejecting templates that no longer match the appraisal's department or company.

opw-6449041

Forward-Port-Of: odoo/enterprise#127566

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 the issue:

- Create a link in editor.
- Copy another URL.
- Select entire link.
- Pasting copied link throws traceback.

This issue happens after merging commit [1] where `normalize_processors` callback returns nothing. After merging commit [2] each processor must return the original root if no processing is needed or processing is in place.

As a result, when this.processThrough("normalize_processors", container) is called from the `insert` method, the next processor in the chain uses `this.editable` as its default argument and removes the FEFF node, which is the anchor node. Later calling closestBlock(selection.anchorNode) returns null, resulting in the traceback. This PR aims to fix the traceback by returning the `root` in processor.

[1]: https://github.com/odoo/odoo/commit/be77a9a2003e09f4621d0ff774bf8749b326d037
[2]: https://github.com/odoo/odoo/commit/17d58d2fdf8da3a69c731fc5ea0d90b95e28efd6

task-6456004






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

Currently, an error occurs when a visitor record is created through the kiosk in Frontdesk.

**Steps to Reproduce;**
 - Install the `frontdesk` module.
 - Go to `Employees` and create a new employee or open an existing one. 
    Set the employee's `email` and `work phone`.
 - Go to `Frontdes` > `Stations` and create a station.
 - Enable `Host Selection` and select that employee.
 - Enable `Notify by email` and remove the `Frontdesk email template`.
 - Open the `kiosk URL`, fill in the information, click `Browse All Hosts`, 
   select that `employee`, and click `Continue`.
 - Error is logged in the terminal.

**Another case:**
 - Clear the `email template`, disable `Notify by email`, and perform `step 6th`.
 - The same error is raised.

`ValueError: Expected singleton: mail.template()`

After [recent commit], when a visitor record is created [1] through the kiosk and the selected 
host has a work email while Notify by email is enabled on the station, the system attempts to 
notify the host by email [2] . During this process, it renders the email body [3] and subject 
using the station's mail template, which raises an error [4] when no mail template is configured.
Similarly, when Notify by email is disabled, if the selected host has no linked user record 
but does have a work email, the notification falls back to email [5]. This also raises the same 
error when no mail template is configured.

This commit ensure a mail template is required whenever Notify by email is enabled on a station.
For the fallback email notification (when the host has no user account), the system checks that 
both a work email and a mail template are available before attempting to send the email, 
since email notifications are not mandatory in this case.

[recent commit]: https://github.com/odoo/enterprise/pull/108297/changes

[1]: https://github.com/odoo/enterprise/blob/d025c1a6a87a90bdaead4195e5f996d058294604/frontdesk/controllers/main.py#L151-L162

[2]- https://github.com/odoo/enterprise/blob/d025c1a6a87a90bdaead4195e5f996d058294604/frontdesk/models/frontdesk_visitor.py#L112-L113

[3]- https://github.com/odoo/enterprise/blob/d025c1a6a87a90bdaead4195e5f996d058294604/frontdesk/models/frontdesk_visitor.py#L128-L131

[4]: https://github.com/odoo/odoo/blob/c76a3aedf523da6f751960d2b5dfbc0016416ef1/addons/mail/models/mail_render_mixin.py#L765

[5]- https://github.com/odoo/enterprise/blob/d025c1a6a87a90bdaead4195e5f996d058294604/frontdesk/models/frontdesk_visitor.py#L108-L111

sentry-7624715784

**Steps to Reproduce:**
- Install the Time Off app and Belgian Payroll (l10n_be_hr_payroll).
- Create and validate an accrual allocation for currently logged-in user with: No end date Any start date An accrual plan configured with a carry-over milestone Any Time Off Type
- Create another allocation for the same employee, using the same accrual plan and same Time Off Type, but with a different start date that is not in the future.
- Select the accrual plan. The error is raised immediately during the onchange.

**Issue:**
- When the accrual allocation onchange computes the accrued balance, a temporary allocation is used internally to simulate the accrual computation.
- This temporary record is discarded after the computation.
- The discarded temporary record can remain pending for computed field recomputation.
- When the onchange later triggers recomputation, the stale temporary NewId can cause: `KeyError: <NewId origin=18>`

**Root Cause:**
- Temporary allocations created with 'new(origin=allocation)' can add computed fields to `env.transaction.tocompute`.
- `invalidate_recordset()` clears the temporary record's cache but does not remove the `NewId` from the pending recomputation queue.
- Since the temporary record has no database row to recompute from, the NewId can later be picked up during recomputation.
- This can lead to a KeyError when the framework tries to access cached data for the discarded temporary record.

**Solution:**
- Properly discard temporary allocations after the accrual simulation.
- In addition to invalidating the cache, remove the temporary NewId from `env.transaction.tocompute` using `remove_to_compute()`.
- Use this cleanup for temporary allocations created with `new(origin=...)`.

**Result**
- Prevents the KeyError during accrual allocation onchange.
- Allows users to create another allocation with the same accrual plan without triggering the RPC error.

**opw-6390559**

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

Forward-Port-Of: odoo/odoo#283772

When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted.

Wrap the search_count call in _updateMatchingRecordsCount (property_definition.js) in a try/catch and show no count when it fails. This is the only place the editor counts matching records, so guarding it here handles a bad domain from any source, the field selector or the code editor. The field selector still shows its warning on the invalid path, so the user can fix or delete the property.

Steps to reproduce:
1. On a model that has a Properties field, add a Many2one property and set its Model to a model that itself has a Properties field.
2. Open the property Domain and click New Rule.
3. In the field selector pick the Properties entry, then close the selector.

=> An error dialog appears and the property can no longer be edited or deleted.

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

Forward-Port-Of: odoo/odoo#283802
Forward-Port-Of: odoo/odoo#259886

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

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

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:
- Create a pricelist with a rule applied on a product category and make it available in the PoS
- Open a PoS session
- From the backend, create a product in a new category covered by such a rule
- Back in the PoS, find that product through Search > Search more and add it to the order

Issue:
The product is priced at its sale price, the pricelist rule set on its category is ignored.

Cause:
A product that is not part of the initial payload is loaded on the fly by load_product_from_pos, which sends back the rules returned by get_pos_ui_product_pricelist_item_by_product. That domain only matches the rules set on the template or on the variant, never the ones set on a product category, and the payload carries no product.category record either. The client therefore has neither the rule nor the category: parentCategories walks categ_id, which resolves to nothing, so getCategoryRulesIds returns no rule and getPrice falls back to the sale price.

This stayed unnoticed because product.category is fully loaded when the session starts, along with every category rule, so only the categories created after the session was opened are missing.

Fix:
Send the categories of the loaded products, since a rule set on a parent category applies to its children - along with the products, and match the rules set on those categories in get_pos_ui_product_pricelist_item_by_product.

The initial loading domain of product.pricelist.item no longer filters the category rules on the loaded categories: such a rule has to be loaded whatever the products sent to the client are, since a product of that category may be loaded later on.

opw-6477745

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

Forward-Port-Of: odoo/odoo#285411
Forward-Port-Of: odoo/odoo#284660

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

Two related Nilvera e-invoice issues affecting Turkish companies:
- The "Fetch Nilvera PDF" button appeared for every company, not just Turkish ones.
- Sending/fetching e-invoices (or fetching the PDF) as a non-admin Invoicing user raised an
  AccessError, because the company's Nilvera API key field is restricted to System/Settings users
  and several call sites read it without `.sudo()`.

## Current behavior before PR:

- The PDF-fetch button shows on both the list view and form view of `account.move` regardless of
  the company's country.
- An Invoicing-only user (no System/Settings access) gets an AccessError when sending/fetching
  e-invoices or fetching the PDF, because `_get_nilvera_client` reads
  `company.l10n_tr_nilvera_api_key` without `.sudo()`.

## Desired behavior after PR is merged:

- Both buttons are only visible for Turkish companies (the list-view button has no bound record, so
  its gate is driven by a new `l10n_tr` session_info/JS context injection instead of a direct field
  reference).
- Invoicing users can send/fetch e-invoices and fetch the PDF without hitting an AccessError.

## Things to add on forward-port

The `.sudo()` fix lives inside `_get_nilvera_client` itself (`l10n_tr_nilvera/lib/nilvera_client.py`),
so every caller that goes through it is already fixed automatically once this diff forward-ports.
Only call sites that read `company.l10n_tr_nilvera_api_key` **directly**, bypassing
`_get_nilvera_client`, still need their own `.sudo()`:

### 19.4
- [x] Fix e-Dispatch/e-Receipt fetch gate-check access error (direct read of the API-key field,
      sudo it the same way as `_l10n_tr_nilvera_company_get_documents` in this PR)

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

Forward-Port-Of: odoo/odoo#284951
Forward-Port-Of: odoo/odoo#274312

Steps to reproduce:
- Argentinean company, Responsable Inscripto (l10n_ar_pos installed)
- A posted customer invoice with VAT, partially paid
- In the PoS, pick the customer, "Settle invoices", select that invoice, pay the balance by bank transfer and validate

Issue:
Validation fails with "There should be a single tax from the "VAT" tax group per line, but this is not the case for line ..." and the settlement cannot be recorded at all. The invoice being settled is correct; the rejected line belongs to a second invoice the PoS creates for the settlement itself.

Cause:
`setToInvoice` already refuses to invoice a settlement, but its condition, `is_settling_account and no line`, only describes a deposit: the deposit line is added at validation. When settling a due or an invoice, `is_settling_account` stays false and the order does carry lines - the settle lines - so the guard never fires. l10n_ar_pos then sets `to_invoice` on mount, as a sale must generate an electronic document in AR, and the settle line, untaxed on purpose since it pays an existing document rather than selling anything, reaches `_check_argentinean_invoice_taxes`.

Fix:
Refuse the flag as well when every line is a settle line. Such an order generates an empty document - all its lines, the receivable one included, have a zero balance - so it records nothing and only consumes a document number, which in AR means an AFIP number for a zero-amount invoice. An order that also sells something keeps its invoice, since the sale still has to be reported. Reconciliation is unaffected: it happens in `_reconcile_account_move_lines` at session close, and is already covered for both invoiced and non-invoiced settlement orders.

opw-6464675

Forward-Port-Of: odoo/enterprise#129902
Forward-Port-Of: odoo/enterprise#128975

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

*=helpdesk_planning_field_service{,_sale_timesheet}

Steps to reproduce:
-------------------------
1. Install helpdesk_planning_field_service_sale_timesheet with demo data.
2. Open a helpdesk team (e.g., Customer Care) and enable field service planning.
3. Create a new ticket in Customer Care, plan two interventions, and mark them as completed.
4. Click the cog menu of the helpdesk ticket and click Preview.
5. In preview mode, click **Field Service** in the left sidebar.

Issue:
---------
A traceback occurs:
```python
File "/home/odoo/odoo/community/odoo/addons/base/models/ir_qweb.py", line 875, in _render_iterall
    raise QWebError(qweb_error_info) from error
odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the template:
    KeyError: 'format_datetime'
    Template: planning_field_service.portal_my_field_service_report_list
    Reference: 866
    Path: /t/t/t[3]/t/tbody/t/tr/td[1]/a/t
    Element: <t t-out="format_datetime(intervention.start_datetime, dt_format='MMM d, YYYY')"/>
```

Cause:
---------
https://github.com/odoo/enterprise/blob/28637781cd3ffc4c3dc0c2016dd5d6051793f641/helpdesk_planning_field_service/controllers/portal.py#L59-L63
After this 6857d1a, date formatting was changed to use `format_datetime`, and [planning_field_service](https://github.com/odoo/enterprise/blob/28637781cd3ffc4c3dc0c2016dd5d6051793f641/planning_field_service/controllers/portal.py#L42) was updated accordingly. However, `helpdesk_planning_field_service` was not updated to pass `format_datetime` in the template values, causing a **KeyError** when opening the field service intervention list.

Solution:
-----------
Pass `format_datetime` in the template values, following the same approach used in `planning_field_service`.

opw-6467400

Forward-Port-Of: odoo/enterprise#128519

Steps to reproduce
------------------
1. Open a restaurant PoS with a preparation display.
2. Add a product, put the internal note "A" on the line, press Send.
3. Change the note from "A" to "B", then open the note again and click "discard", that will clear it.
4. Press Send.

-> The line is fully cancelled on the preparation display and the same quantity is sent again as a new order.

Expected Behavour
-----------------
The existing line should be updated in-place instead of cancelling and re-creating a new one.

Why it's happening
------------------
In `_process_preparation_changes` we calculate a key for every line and the `note` is inside this key.

For the order lines we take `line.note or "[]"`, but for the note history we take `note['new'] or ''`, in that case, the keys don't match, so we cancel the current one and create a new line!!

The fix
-------
We use `"[]"` now, in many places (for completness), a follow up of 484ef2e8b2b.

opw-6467346

Forward-Port-Of: odoo/enterprise#128601

### Current behavior:
After the order is marked as "Completed" in the Kitchen Display, it reappears in the "Almost There" status and remains there indefinitely. The order only disappears after closing the POS session.

### Expected behavior:
Once an order is marked as "Completed" in the Kitchen Display, it should be removed from the Order Status Screen.

### Steps to reproduce:
1. Open Restaurant POS, Kitchen Display, and Order Status Screen
2. Send an order to the kitchen
3. Move To cook > Ready > Completed
4. Observe the order return to "Almost there" instead of disappearing

### Cause of the issue:
- `get_preparation_display_orders_domain` compares `stage_id` to 'last_stage_id' and uses `todo=True`, so the last-stage exclusion never matches. Finished last-stage lines stay in the fetch; `_get_pos_orders` then puts any non-Ready leftover into Almost there.
 - Bug introduced by commit https://github.com/odoo/enterprise/commit/8491f7a74363f7de4fd542e0de0b2f06f00f01ae
(PR https://github.com/odoo/enterprise/pull/108760).

### Fix:
Restore the saas-19.3 domain: exclude lines that are `todo=False` on `self.stage_ids.ids[-1]`.

opw-6470260

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

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

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

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

Steps to produce:
---
- Create a company with `Argentina` as the country.
- Switch to the newly created company.
- Create a new website for the `Argentina company`.
- Create a pricelist with a `23%` discount on the sales price for all products.
- Create a new product, set the sale price to 100, remove all tax, and publish.
- Go to the website and switch to the newly created Argentina company website.
- Go to the Shop page and open the product.

Issue:
---
- The tax-excluded price (`Precio s/Imp. Nac.`) displayed on the shop catalog card differs from the tax-excluded price displayed on the product detail page.

Root cause:
---
- In `_get_additionnal_combination_info`, [1] returns the unit price with the pricelist discount already applied. However, when `combination_info['has_discounted_price']` [2] is `True`, the method applies the discount again manually, resulting in the pricelist discount being applied twice on the product detail page.

Solution:
---
- Remove the redundant discount calculation block. This ensures that the tax-excluded price displayed on the product detail page matches the price shown on the shop catalog card.

[1]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L61-L62
[2]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L71-L74

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

Forward-Port-Of: odoo/odoo#283761