Currently, an error occurs when a user tries to create a helpdesk team record.

**Steps to Reproduce:**

 - Install the `helpdesk` module without demo data.
 - Go to `Settings` > `Technical` > `Email` > `Email Templates` and delete the 
   `Helpdesk: Ticket Received` template record.
 - Go to `Helpdesk` > `Configuration` > `Stages` and remove all records.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams` and click `New` to create a record.

`AttributeError: 'NoneType' object has no attribute 'id'`

When the user deletes all stages, the system attempts to create a new stage and assign the 
"Helpdesk: Ticket Received" mail template to it [1]. However, if this template record does not 
exist, accessing its id raises the error.

This commit ensures that the template record exists before accessing its id, otherwise, None is 
passed as the default value.

[1]: https://github.com/odoo/enterprise/blob/32187f79fb0a595497a5e77db4b22b417b03b8dd/helpdesk/models/helpdesk_team.py#L34

sentry-7482994877

Forward-Port-Of: odoo/enterprise#117446

Currently, an error occurs when a user selects a shift template on a planning slot.

**Steps to Reproduce:**

 - Install the `Planning` module with demo data.
 - Create a `Resource Time Off` record with `start` and `end date` separated by more than 
  `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week.
 - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create 
   a `new one`, and set the `Working Days` to more than 1 day.
 - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above 
   `shift template`.

`AttributeError: 'bool' object has no attribute 'replace'`

This error occurs because when the user sets the shift template, the compute method runs to 
calculate the start and end datetimes [1]. It computes the end datetime by adding the template 
duration in working days from the given start datetime using the resource working calendar within 
a searchable range of around 1400 days [2]. During this computation, leaves and non-working days 
are skipped [3]. If no valid working interval is found within the searchable range, then it returns 
False [4], which raises the error [5].

This commit ensures that if plan_days returns False, the computation falls back to the previously 
calculated end date.

[1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671

[2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835

[3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537

[4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835

[5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654

sentry-7472958590

Forward-Port-Of: odoo/enterprise#117073

Steps to reproduce
1. Install hr_holidays and hr_contract.
2. Take a demo employee currently on a validated time off covering now.
3. Set the employee's running contract Working Schedule to empty (fully flexible).
4. Run the "HR Contract: update state" cron (or otherwise leave the contract in state open / close, or draft + kanban Ready).
5. Open the Employees app or any view rendering that employee's chatter / follower panel.

Issue
A traceback "Expected singleton: resource.calendar()" is raised. If the employee's chatter is open, the failing compute is re-fired on every store refresh and the UI becomes unusable.

For fully flexible contracts, hr.contract has no resource_calendar_id, so _get_calendar_periods appends period tuples with an empty calendar recordset (https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/hr_contract/models/hr_employee.py#L184). _get_first_working_interval then forwarded that empty recordset to _work_intervals_batch, which calls ensure_one() and crashes.

This regressed when _compute_leave_status was switched from a single calendar lookup to per-period iteration in
https://github.com/odoo/odoo/commit/bf73b63eec56a822edec2d9ecfeb231a0fbfbbe8 which did not consider that a period in the chain can come from a contract with no calendar.

Solution
Fall back to the company's calendar when the period's calendar is empty, matching the guard already present from saas-18.4 onwards in https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759.

opw-6168264

Forward-Port-Of: odoo/odoo#261995

**Problem:**
account move created by stock valuation layer 
does not take analytic account from PO

**Steps to reproduce:**
- make sure you have at least one analytic account
- create a storable product with categ standard automated
- set a positive cost
- create a PO for 1 quantity 
- on the PO line of the product, in the analytic distribution 
column (might need to be unfiltered) set an analytic account
- confirm PO and validate receipt
- click on the valuation smart button and on the book widget
of the stock valuation layer

**Current behavior:**
the account move lines have no analytic distribution

**Expected behavior:**
The account move lines should inherit the analytic account 
from the purchase order line like it's the case for the bill.

For the analytic distribution of the Bill, the selection is : 
1) take analytic distribution from PO if one
2) if not, take from distribution model if there is one
3) empty

Currently for the account move lines of the svl the selection is: 
1) take from distribution model if there is one
2) empty
But we should use same selection as for the bill

**Cause of the issue:**
When setting the analytic distribution we first 
try to use the one from PO/SO by calling 
_related_analytic_distribution()
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157
But since the account move lines have no purchase_line_id
no analytic distribution will be returned
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545


opw-6022695

Forward-Port-Of: odoo/odoo#264436
Forward-Port-Of: odoo/odoo#263236

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#264948
Forward-Port-Of: odoo/odoo#262591

Refunding a customer account order was introduced by this commit: https://github.com/odoo/enterprise/commit/5a1af0db647563cffcb796a257ad01c0d0c9af91

The goal was to show both the original order and its refund in the settlement list and allow settling them together.

This works in 18.2 where the feature was introduced, but it causes issues in later versions.

The main issues are:
- Refunded order still appears after the full order is refunded and a new order was created and paid by customer account.
- When two orders exist and the larger one is settled first, the second order cannot be settled correctly.

How to reproduce:
- Create OrderA with AmountA
- Create OrderB with AmountB < AmountA
- Settle OrderA
- Try to settle OrderB: it cannot be found
- Settling by amount shows incorrect values due to negative customer_due_total for settlement orders.

The fix:
Restore the original settlement behavior and handle customer account refunds the same way as settlement orders.

opw-6192248

On /shop, when a snippet block sits above the searchbar, the search dropdown was rendered partially hidden behind that block (cropped/unreadable items).

Steps to reproduce:
===================
1. Go to /shop.
2. Add a snippet block above the searchbar.
3. Type in the searchbar.

=> Observed: search results appear cropped, with upper items
   hidden behind the snippet block above.

Root cause:
===========
the products grid column (`#products_grid`) has `overflow: auto`, https://github.com/odoo/odoo/blob/d9bb1c1dc90f97b63b87ad762fc4ab36abf7e05f/addons/website_sale/static/src/scss/website_sale.scss#L442 which clips any absolutely-positioned descendant
that extends past its bounds. The dropdown's containing block is the searchbar `<form>` (position: relative), which lives inside that column. When the dropdown grew (or flipped to dropup) and extended outside the column, the part outside was clipped, and any positioned snippet siblings above the column painted over the clipped area.

Fix:
======
while the dropdown is mounted, lift the `overflow: auto` on its ancestor `div.col` so the menu can extend past the column and paint on top of other content. Done from JS so no SCSS rule has to target the searchbar-specific column.

opw-6216317

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