Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete.

### Steps to reproduce

1. Create many messages, ensuring some are hidden from a specific user via access rules.
2. Open the message list view as that user.
3. Pagination incorrectly shows a total matching the current page (e.g., "1-68 / 68") instead of the full count (e.g., "1-80 / 5000+").
4. Because the system believes all records are displayed, the "Next" page button is disabled, leaving the user stuck on the current page despite more records existing in the database.

### Cause

The `mail.message` model filters records in Python after fetching them from the database to enforce complex access rules.

1. The system queries the database for a batch of records up to the view's limit.
2. The `_search` method removes inaccessible records from this batch.
3. The web client receives fewer records than the requested limit.
4. Interpreting this as the end of the dataset, the web client skips the count query and displays the current batch size as the total.

### Fix

Add `'force_search_count': 1` to the action context. This forces the web client to execute a separate count query to determine the total number of records, regardless of the batch size returned.

opw-5425361

When searching on the Website site, using the main search on the navbar, it opens a list view with the results (`website.list_hybrid`) which raises the warning on the logs (2 times):
"Unknown directives or unused attributes: {'t-key'} in website.list_hybrid"

![Task 79454 - Issue 434 - Image of Warnings](https://github.com/user-attachments/assets/f5a3100b-c617-4c38-a8b5-f42427a4317c)

This happens after the attribute `t-key` was added to the template [\[1\]] because the template is only used in QWeb. The validation for them doesn't include the `t-key` [\[2\]] as one of the "iter_directives" nor has a `_compile_directive_*` method to check and remove it from the validation as it's done with the `t-as` and `t-foreach`.

This also causes the raise of the warnings on tours that use the tour method `searchProduct` (of the module `website_sale`) because it uses the first input with the name of search and happens to be the search on the navbar.

![Task 79454 - Issue 434 - Search Input](https://github.com/user-attachments/assets/923f5d63-5cfb-4c0b-a563-0eabc04882bb)

[\[1\]]: https://github.com/odoo/odoo/commit/7b1d82aa
[\[2\]]: https://github.com/odoo/odoo/blob/f52cfb09/odoo/addons/base/models/ir_qweb.py#L1400

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

Forward-Port-Of: odoo/odoo#179017

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#272161

For a logged-in user, some form fields are automatically prefilled from
their profile, such as a "Phone" field with their phone number.

**Issue:**
The prefill configuration is always preserved when we change options of
a field. While this is correct when updating few options, but it also
happens after the field is repurposed, causing it to inherit a prefill
value intended for a different field.

**Steps to reproduce:**
- Edit the /contactus page's form.
- Change the "Name" field's type to a "URL" or "CC" field.
- Save the changes.
- The "URL/CC" field is prefilled with the user's name.

A field is considered repurposed when:
- its type is changed (e.g. from "Phone" to "URL");
- a custom field is converted into an existing field.

**Fix:**
This commit preserves the prefill only when the field keeps the same
name and type. Otherwise, it clears the stale prefill so repurposed
fields no longer inherit incorrect values.

task-[5976747](https://www.odoo.com/odoo/project/974/tasks/5976747)

Forward-Port-Of: odoo/odoo#275812

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941