Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

Forward-Port-Of: odoo/enterprise#114464
Forward-Port-Of: odoo/enterprise#113317

Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date.

**Steps to Reproduce:**
- Install the MRP module (with demo data).
- Activate "**Custom Work Order Dependencies**".
- Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM.
- Confirm and plan the MO.
- Remove both start and end dates of any dependent operation.
- Manufacturing > Planning > Work Orders > Gantt
- Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1').

**Error:**
`TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'`

**Cause:**
At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2].

Fix:
This commit adds a condition before date comparisons to ensure the dates are defined.

[1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284
[2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491

sentry-7377739830

### Issue:
When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead

For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040`

### Cause:
The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report

### Note:
The example above uses a Belgian fiscal position to reproduce the issue

Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default

A related fix makes the Intervat settings available in that case
Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15

### Steps to reproduce:
- Disable demo data and install `accountant`
- Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040)
- Click the alert to install the Belgian taxes
- Create and confirm an invoice for a Belgian customer:
  - Fiscal Position: Belgium
  - Any product with a Belgian tax
  - Invoice Date: 01/01/2026
- Open the Tax Report and select `VAT Return (BE)` for January
- Click `Returns` and select the full year
- Mark the December return as Completed from the three-dot menu
- Review January and fill the missing company data (TIN: 1111111, phone and email)
- Click `Validate -> Lock -> Submit`

### Before the fix:
The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`).

opw-6076540

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

sale: add sale order specific hook to extend page values
------

Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values

sale_timesheet: hide 'View Timesheets' button for users without access
-------

Steps to Reproduce:
-----------------
   - Create a product with the invoice policy set to Based on Timesheets
   - Enable Project and Tasks on the order.
   - Create and confirm a sale order using a portal user.
   - Log timesheets on the related task.
   - Create an invoice from the sale order.
   - Log in as the portal user and open the invoice.
   - Click the 'View Timesheets' button.
    
 Issue:
-------------
   The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.

Root Cause:
------------
 The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
    
 Fix:
-----------
   We replaced the timesheet_count check with a check that verifies  whether the user actually has access to any of the related timesheets.
    
task-4745519

Forward-Port-Of: odoo/odoo#209552

The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty.

Steps to reproduce:
1. Create and pay a POS order with a product that has taxes
2. Go to the backend (Point of Sale > Orders) and open that order
3. Initiate a return for the order
4. In the return order, add a new product (exchange scenario)
5. Observe that taxes are correctly shown on the new line
6. Click Save
7. The taxes disappear from the order line

The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views.


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