Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Switch to `mobile view`.
- Now search for `drawer` in product search.

Issue:
---
- In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed.

Root cause:
---
- At [1], in the search template definition, the action attribute is missing in the search form.

Solution:
---
- Set the form action using keep(search=0) instead of leaving it undefined.
- This ensures that the search behaves correctly depending on the context (global or category-scoped).

[1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259

opw-5992052

---


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

Forward-Port-Of: odoo/odoo#251694

Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#250065
Forward-Port-Of: odoo/odoo#219081

Problem
------------------------
When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce:
1. Create allocated leave for employee and approve and validate it.
2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect.

Objective
---------------------------
Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable.

Solution
--------------------------
Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created.

Task: 5911074





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

Forward-Port-Of: odoo/odoo#253425
Forward-Port-Of: odoo/odoo#249527

Currently, certain `valid GSTINs` for Non-Resident taxpayers are not 
recognized by the partner `autocomplete` feature.

**Steps to reproduce:**
- Install the `l10n_in` and `partner_autocomplete` modules.
- Navigate to Settings > Users & Companies > Companies.
- Click `New` and set `Tax ID` to `9922JPN29001OSU`.
- Wait for 5–10 seconds.

**Observation:**
The partner autocomplete does not trigger, although it is valid and verifiable 
on the official GST portal: https://services.gst.gov.in/services/searchtp

**Root Cause:**
The issue was already fixed in core validation by PR [1], but the 
GSTIN validation logic used in partner autocomplete was not updated.

At [2], the GSTIN validation regex for NRI taxpayers only supports 
formats ending with `NRX` (X = any alphanumeric character). However, 
certain valid GSTINs follow a revised structure and therefore are not 
matched by the existing regex.

**Fix**:
This commit ensures that valid NRI GSTIN formats are accepted 
during validation by applying a fix similar to [1] to the partner 
autocomplete GSTIN validation at [2].

Related IAP PR: https://github.com/odoo/iap-apps/pull/1491

[1]:
https://github.com/odoo/odoo/pull/251760

[2]:
https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52

Forward-Port-Of: odoo/odoo#253799

Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error:

```
[toBe] expected values to be strictly equal (Element .o-mail-NotificationMessage:contains(notification 0) not found in viewport of .o-mail-Thread)
```

This happens because while the test is awaiting the scrolling to unread, this is made with just an `await tick()` after opening discuss app. This is not enough: messages need to be loaded and then there's a tick with scroll to unread message.

The awaiting of messages being loaded was missing in the test, which this error is fixing. This is important because the opening of pinned panel and click on jump may be triggered before the auto-scroll to unread message, and this is a problem because the jump to pinned message would be cancelled by the scroll to bottom.

Also instead of awaiting the tick for scroll to unread message, this commit replaces it by assertion of message list being at the bottom. This asserts precisely the scroll has happen, and its ok to have it scroll at bottom as the last message is short and is necessarily smaller than viewport, thus the auto-scroll to this unread message implies this scrolls to the bottom of message list.

Fixes runbot-error-238427

Forward-Port-Of: odoo/odoo#253928

…f uom

**Problem:**
partial cogs are computed incorrectly when 
the uom of the invoice is different than the one 
of the product

**Steps to reproduce:**
-1) created a stored product with category std price perpetual
-2) set a cost of 1 and an on hand quantity of 12
-3) for the invoicing policy select 'delivered quantities'
-4) in the sales tab add the packaging 'pack of 6'
-5) confirm a sale order for 2 packs of 6

Problem A: 
-6a) validate the delivery
-7a) create and confirm an invoice for all the quanity 
-8b) on the delivery create a return for a quantity of 6 and validate
-9b) select 'create invoice' on the sale order
-10b) confirm the credit note

Problem B: 
-6b) change the quantity to 6 units on the delivery
-7b) validate with backorder
-8b) create and confirm an invoice for the delivered quantity
(1 pack of 6)
-9b) validate the back order
-10b) create and confirm an invoice for the remaining (1 pack of 6)

**Current behavior:**
Problem A : 
the cogs lines are : 
- crediting stock valuation of 54$
- debiting expenses of 54$

Problem B: 
the cogs lines are: 
- debiting stock valuation of 24
- crediting expenses of 24

**Expected behavior:**
Problem A:
the cogs lines should be: 
- debiting stock valuation of 6
- crediting expenses of 6

Problem B: 
the cogs lines should be: 
- crediting stock valuation of 6
- debiting expenses of 6

**Cause of the issue:**
Both problems have the same cause.
To compute the price unit for the cogs we call _get_cogs_value()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value, in the computation of the return value:
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L74
- price_unit is computed (in both use cases) using _get_cogs_price_unit
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L68
and is expressed in the uom of the product 
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/stock_move.py#L238-L240
- self.quantity is expressed in the uom of the invoice (pack of 6)
- cogs_qty is computed using _get_cogs_qty()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L66
and is expressed in the uom of the invoices (pack of 6)

Because of this, in both use cases, the computation is incorrect.

**fix:**
we use the uom of the product everywhere because _get_cogs_value()
should return the price unit in the products uom
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L51-L52

opw-5901706

Forward-Port-Of: odoo/odoo#250154

Currently on creating a time off that falls under a past contract still generates timesheet hours based on the employee's current contract.

### **Steps to Reproduce:**
1) Install `project_timesheet_holidays` module with demo data. 
2) Create an employee with two contracts/versions:
-  Past contract: 1 Jan 2025 to 31 Dec 2025 with standard 40h/week (8h/day).
-  Current contract: 1 Jan 2026 to indefinite with standard 35h/week (7h/day). 
3) Create and validate Time off for this employee in the past (e.g, 29 Dec 2025) 
4) Navigate to `Timesheets>All Timesheets`, search for this employee and switch
   list view for clear view.

### **Observed Behavior:**
7:00 hours are displayed on the timesheet, pulling from the employee's current active contract calendar.

### **Expected Behavior:**
8:00 hours should be displayed, as the leave date falls under the 40h/week past contract.

### **Root Cause:**
In the `_generate_timesheets`, the caledar values is fetched using `employee_id.resource_calendar_id` see[1], which always points to the employee's currently active calendar. Furthermore, this calendar is not explicitly passed to `_list_work_time_per_day` see[1], causing the method to fall back on the current default.

[1]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/project_timesheet_holidays/models/hr_leave.py#L36-L55

### **Fix:**
Change the logic to use `leave.resource_calendar_id`, which correctly computes and retrieves the resource calendar active during the specific `date_from` and `date_to` of the leave and pass this `calendar` to `_list_work_time_per_day` to ensure the correct historical hours are used for timesheet generation.

**opw-5922695**

Forward-Port-Of: odoo/odoo#248207