This PR improves the cost of `/forum/my-forum-1/my-slug-1234` by ~48%.

This has a huge impact on odoo.com

The `/forum/...` routes are the `#1` on odoo.com in terms of absolute count and in terms of CPU and SQL cost. They are called several million times a day. 

The average total time for `/forum/my-forum-1/my-slug-1234` goes from ~358ms to ~187ms (sql: 107ms -> 52ms - cpu 250ms -> 135ms)

This has been tested by extracting 30k real forum post urls from odoo.com logs and replaying them on a staging server. That day `/forum/...` routes were called 2.8M times

## before
<img width="1343" height="122" alt="image" src="https://github.com/user-attachments/assets/2b8264b7-4f26-40a7-a20a-20d478f5a93a" />

## after
<img width="1339" height="124" alt="image" src="https://github.com/user-attachments/assets/7c73aeb0-a4b4-45b8-ae98-093ac70c438e" />



### First commit

before
<img width="1857" height="946" alt="image" src="https://github.com/user-attachments/assets/63b9d966-f5fd-4047-b4cb-533b7e9491bc" />


after

<img width="1844" height="867" alt="image" src="https://github.com/user-attachments/assets/9494efe0-0b7c-419d-b918-dcfe5e942e63" />


query plan for most used tags as public user:

- with the index https://explain.dalibo.com/plan/gbf9fbd358687f3e
- without the index https://explain.dalibo.com/plan/da5gg6cd27f67496

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

**Problem:**
When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete.

**Cause:**
The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records.

**Solution:**
Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone).

**Performance Stats:**
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|100         |3.1s       |393           |0.8s      |117          |
|1,000       |22.3s      |2,090         |1.5s      |183          |
|10,000      |Timeout    |N/A           |6.7s      |541          |

opw-6087422

Forward-Port-Of: odoo/odoo#270684
Forward-Port-Of: odoo/odoo#263953

Currently, an error occurs when a user removes the payslip date.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and remove the `start` or `end` period.

**Error 1:**
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

**Error2:**
`AttributeError: 'bool' object has no attribute 'month'`

When a user removes the start or end date of a payslip, the system computes the Average Daily Wage. 
Based on the payslip dates, it finds the previous year's payslips [1]. If the start or end date is not set, 
it raises an error [2].
For the second error, when computing whether to include EOY pay, it compares the company's EOY 
pay date with the end date's month. If the end date is not set, accessing its month raises an error [3].

This commit ensures that when retrieving previous-year payslips, if the start or end date is not set, 
it returns an empty payslip recordset. It also ensures that when computing whether to include EOY 
pay, if the end date is not set, `include_eoy_pay` is set to `False`.

[1]: https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L124

[2]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L209-L215

[3]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L141

Forward-Port-Of: odoo/enterprise#120586

Steps to reproduce:
-------------------------------------------
1. Install the Timesheet module with demo data
2. Go to any FSM task > set allocated hours to 20h
3. Fill the timesheet for the same task for 10h
4. Navigate to FSM > My Tasks > Gantt view

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />


After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />


opw-6038983

Forward-Port-Of: odoo/enterprise#122899
Forward-Port-Of: odoo/enterprise#111270

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

Forward-Port-Of: odoo/enterprise#122994
Forward-Port-Of: odoo/enterprise#122297

Before this commit, joining a call in a mobile browser (Chrome, Safari, ...) would crop the bottom call controls (mic, camera, hang-up, ...) behind the browser's chrome (URL bar / bottom nav).

On mobile, entering the meeting uses the fullscreen overlay with `keepBrowserHeader: true`, so no native fullscreen is requested and the browser UI stays visible. The overlay was sized with the Bootstrap `vh-100` class (`height: 100vh`), and `100vh` resolves to the *large* viewport (as if the URL bar were hidden). Combined with `fixed-top`, the overlay extended past the visible area and pushed the control row off screen.

This commit sizes the overlay with `100dvh` (dynamic viewport height) instead, which tracks the currently visible viewport and shrinks while the URL bar is shown, keeping the controls on screen. This is a no-op in native/desktop fullscreen where `dvh == vh`, and matches the `dvh` usage already present in the codebase (welcome page, bottom sheet).

task-6353266


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

Forward-Port-Of: odoo/odoo#273949

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#267279
Forward-Port-Of: odoo/odoo#263058

When Google sends an all-day event, the payload only contains a date (no time), so the inbound sync stores start and stop at 00:00 UTC. The list view renders those Datetime fields in the viewing user's timezone, so any user west of UTC sees the previous day. The calendar view stays correct because it reads the date part directly.

The rest of Odoo stores all-day events at 08:00 and 18:00 UTC, which keeps the stored datetime inside the same calendar day:
https://github.com/odoo/odoo/blob/327ad9b737b0f1d4c547c71a52c45d8433f2b3f4/addons/calendar/models/calendar_event.py#L408-L414

Apply the same 08:00 / 18:00 normalization when building values from a Google all-day payload, so events created on Google match events created in Odoo.

Steps to reproduce:
1. Set your user timezone to America/Winnipeg.
2. Connect a Google account and run the calendar sync.
3. In Google Calendar, create an all-day event on January 31.
4. Sync, then open Calendar in list view in Odoo.

=> Start Date and End Date columns show January 30.

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

Forward-Port-Of: odoo/odoo#271573
Forward-Port-Of: odoo/odoo#262282

Login uniqueness is enforced by a `UNIQUE (login)` constraint that Postgres compares byte for byte, so signing up with foo@example.com and then Foo@example.com produces two separate accounts pointing at the same real mailbox.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L274

Even if the DB constraint did catch an exact-case duplicate and `_signup_create_user` re-raised it as a `SignupError`, the controller's friendly "already registered" branch only triggers when the duplicate lookup finds a row, and that lookup goes through `_get_login_domain` with an exact `=` operator. Case variants would fall into the generic "Could not create a new account" branch instead.
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/addons/auth_signup/controllers/main.py#L68-L75
https://github.com/odoo/odoo/blob/66a6c16551041543b5addfe846f15e769b4e9afe/odoo/addons/base/models/res_users.py#L749-L750

`_signup_create_user` now refuses creation when a user with the same email already exists, applying to both b2c free signup and token-based invitations. It raises `UserError` directly so the controller's `except UserError` surfaces the message without a redundant lookup. The check uses `_get_email_domain`, whose base implementation is switched from `=` to `=ilike` over a value escaped via `tools.escape_psql` so `%` and `_` are matched literally rather than as wildcards. Its only existing caller is `reset_password`, which already wants case-insensitive matching.

Steps to reproduce:
1. In Settings, set Customer Account to "Free sign up" and save.
2. Log out, then on the login page click "Don't have an account?".
3. Register with foo@example.com.
4. Log out again and click "Don't have an account?".
5. Register with Foo@example.com.

=> Two distinct user accounts are created for the same mailbox.

opw-6199441

Forward-Port-Of: odoo/odoo#263864

### Steps to reproduce:

- Have a company with a branch say "company1" and "branch"
- Create two products: Final product (FP), Component (Comp)
- Set the company_id of FP to "branch" and of Comp to "company1"
- Associate both products with a product category set to avco in company1 (the field is company dependant)
- Create a bom for FP with company_id set to "branch": 1 X Comp
- Impersonate a user whose only allowed and default is "branch"
- Create and confirm an MO for 1 unit of FP
- Set the qty_producing to 1 unit and validate
#### > Access Error: Access to unauthorized or invalid companies.

### Cause of the issue:

Validating the MO will, validate the component move and set its value: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/stock_move.py#L168-L173 But, in order to determine this value, it is necessary to determine its `property_cost_method`:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L60-L69
Now, the issue is that the `product_template` of the component belongs to "company1" so that the user is unauthorized to read the valuation method of the product category for "company1".

opw-6216141

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

Forward-Port-Of: odoo/odoo#274108
Forward-Port-Of: odoo/odoo#272429

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273839
Forward-Port-Of: odoo/odoo#271119

### Issue:
When creating a new Indian company, the `Half Up` cash rounding is reassigned to the new company instead of being duplicated
Previous Indian companies lose access to it, causing errors when opening invoices that reference the cash rounding if the user doesn't have access to that company

### Cause:
`cash_rounding_in_half_up` was defined as a `data` record with a fixed XML ID (`l10n_in.cash_rounding_in_half_up`) `_get_in_account_cash_rounding` referenced that XML ID directly and set `company_id` to the current company on each chart of accounts installation
This reassigned the single shared record to the new company instead of creating a new one

Moving the definition to the `@template` decorator without a module-prefixed XML ID lets the chart of accounts system create one record per company, as intended

### Steps to reproduce:
- Install `l10n_in` and switch to `IN Company`
- Check the Cash Rounding records grouped by company
- Create a new Indian company
- Enable both `IN Company` and the new company
- Check the Cash Rounding records grouped by company again

Before the fix, only the last created Indian company has the Cash Rounding record

opw-6318857

Forward-Port-Of: odoo/odoo#272866

**Issue**
The quantity displayed in the Unit Cost History report can be incorrect when the move UoM differs from the product UoM.

**Steps to reproduce**
- Create an AVCO product Comp tracked in tons with a unit price of 100.
- Create another product with a BoM consuming 100kg of Comp
- Create, confirm and produce a MO for that product
- Open the Unit Cost History for Comp
-> Quantity is incorrect (100 instead of 0.1). As a consequence, the computed added value displayed in the report is also incorrect (10000 instead of 10).

**Cause**
The quantity and added value fields come from the `stock.avco.report` model, which is defined by this SQL view:
https://github.com/odoo/odoo/blob/aef190dbff365f4fe5d92a2c41c35f92b66ce5fd/addons/stock_account/report/stock_avco_audit_report.py#L36-L39 The view uses the `quantity` field of `stock.move`: https://github.com/odoo/odoo/blob/aef190dbff365f4fe5d92a2c41c35f92b66ce5fd/addons/stock_account/report/stock_avco_audit_report.py#L48 
without converting it in the right uom

opw-6271229

Forward-Port-Of: odoo/odoo#269846

Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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

Forward-Port-Of: odoo/odoo#273570
Forward-Port-Of: odoo/odoo#273010

Currently, when a user creates and confirms a scrap order for a product that has multiple lots, only a quantity of 1 is being scrapped instead of the full intended quantity.

## Steps to replicate:
* Install Inventory and enable Lots and Serial Numbers from settings
* Create a product 'screw' tracked by lots.
* Create two lots for the product with on hand quantity of 100 on each lot.
* Create a scrap order > Set lot to second created lot > Set quantity to 50
* Save and confirm the scrap order.
* Go to screw and check the on hand quantity

## Observed Behavior:
Only a quantity of 1 from the lot has been scraped, which is incorrect. According to the scrap order, a total quantity of 50 should have been scraped.

## Root cause:
This issue arises from how inverse methods are triggered when the form is saved.

When saving, the `_set_quantity` method is executed first for the quantity field. This method calls `_set_quantity_done`, which in turn invokes `_set_quantity_done_prepare_vals` [1].

At this stage, there are no existing move lines. As a result, the initial loop in [1] is skipped. Because no move lines are present, the system proceeds to reserve quantities using `_get_reserve_quantity` [2].

Since no `lot_ids` have been set yet (because `_set_quantity` is executed before lot assignment), the reservation follows the warehouse’s default removal strategy, which is FIFO. Consequently, it selects quantities from Lot 1 first.

These reserved quants are then used to prepare move line values [3]. The lot information is taken directly from the quant itself [4], resulting in move lines being created with Lot 1.

**At this point, the system state is:**
**Stock move:**
| Field | Value |
|--------|--------|
| Lot IDs | 2 |
| Quantity | 50 | 
 
 **Stock move line:** 
 | Field | Value |
|--------|--------|
| Lot ID | 1|
| Quantity | 50 | 
 

Next, the inverse method for setting lots, `_set_lot_ids`, is triggered. Since the lot on the move (Lot 2) does not match the lot on the move line (Lot 1), the system schedules the existing move line for deletion (as shown in [5]).

Additionally, because the move’s lot (Lot 2) is not present in the move lines, a new move line is created with at [6]:
**Lot ID :** 2
**Quantity:** 1

<h3>Why didn’t this issue occur in earlier versions?</h3>
In previous versions, scrapping was handled by a separate model (stock_scrap). Move lines and move values were only created when the scrap operation was confirmed.

However, after this [commit](https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba), the `stock_scrap` model was merged into the stock move model. Due to this change, inverse methods are now triggered directly when interacting with the scrap form view, leading to the behavior described above.

[1]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2332-L2399 [2]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2388-L2398 [3]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L2396 [4]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L1755-L1764 [5]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L618-L620 [6]:
https://github.com/odoo/odoo/blob/3a40c7a8e01d5b835db19b46bb45dfbeac7c16cd/addons/stock/models/stock_move.py#L632-L641

## Solution:
By passing `lot_ids` in the context during scrap creation, the system can reserve quantities from the correct lots when setting quantities. This ensures that the lot assignment is consistent from the beginning.

As a result, the `_set_lot_ids` logic executes correctly, avoiding unnecessary deletion of existing move lines that would otherwise occur due to mismatched lots between the move and its move lines.


opw-6109494

When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#273565
Forward-Port-Of: odoo/odoo#270827