Version:
----------
- 18.0+

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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

Forward-Port-Of: odoo/odoo#269909
Forward-Port-Of: odoo/odoo#262396

When checking if a stock.move.line can use a location as destination with the method `_check_can_be_used()`, we start by checking if the incoming products can be stored without exceeding the maximal weight of the location.

This needs to call the `_get_weight()` method to compute the forecasted weight for the location. This method relies on heavy computations and can become a bottleneck when we need to loop over a high number of locations.

In some cases, we can rule out the location based on less expensive conditions that are verified after the weight one.

We propose to invert the conditions check order to avoid computing the location weight when other conditions are not met.

Steps to reproduce
---------------

- Install stock and purchase modules;
- Enable storage locations and categories in the settings;
- Create a storage category: allow_new_product = same, max_weight=10.0 kg;
- Create N locations using this category, parent_id=WH/stock;
- Create a putaway rule to each location from WH/stock, for the new storage category and using a product A with a weight of 2 kg;
- Create a stock.quant per location to store a product B, weight=2kg;
- Create a purchase order with X lines for 1 unit of product A;
- Validate the purchase order.

The validation should take several seconds to execute
as every locations will be rejected due to the storage
category, but it will call _get_weight() first.

Benchmark
---------------

This improvement is very data specific and will be most useful when a lot of locations are using a storage category of type "empty" or "same".
In addition, it also relies on the order in which we are treating the locations, if the acceptable locations are the first to be received in the method, it won't need to loop over all of them.

The following benchmark was established in a production database in which every 6068 locations are using a category of type "same".

| No stock.move.lines | Before PR | After PR |
|---------------------|-----------|----------|
|                  40 |     168 s |   7.3  s |
|                  72 |     264 s |  12.33 s |

When the only condition that can reject locations is the exceeding weight, this modification will slow down the process. However, the time loss in this case is smaller than the gain in the first case.
The following benchmark was obtained by validating a purchase 1 line order with only fully filled locations.

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     2.02s |   2.37 s |
|         2000 |     7.85s |   9.76 s |
|        10000 |   39.16 s |  48.86 s |

opw-5949370

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

Forward-Port-Of: odoo/odoo#266872

### Issue
On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language

When an expense is first generated up to 19.0, it requires a name and is temporarily given a localized placeholder like "Dépense sans titre..." in French

When the OCR results arrive, the system is supposed to detect this generic fallback string and overwrite it with the real extracted description

However, because of a language mismatch, the system fails to recognize its own placeholder. It incorrectly assumes the user manually entered that text and, to prevent losing user data, refuses to replace it

Before the fix, the title remains stuck on the placeholder
In very rare cases, the translation applies correctly, but it fails most of the time

### Cause
The OCR successfully finds the correct description, but in `_fill_document_with_results`, the expense name is not replaced

This seems to happen because `self` in `self._get_untitled_expense_name("")` carries a residual context that could override the correct language to use during the automated extraction process

Even though the user record and the detected language are correctly set to the alternative language, `default_receipt_name` appears to be generated in English ("Untitled Expense")

This would cause the subsequent string comparison with the actual translated name stored in the database to fail, blocking the update

### Fix
I made some tests in some generated RunBot and the user is correct and also the associated lang

I supposed self was containing lang details overriding the correct language to use

`self.env['hr.expense'].with_context(lang=user_id.lang)` seems to be working

### Steps to reproduce
The issue cannot be reproduced locally, follow these steps on a Runbot instance:
- Retrieve IAP OCR credentials from a trial database
- Enable Developer Mode in Settings
- Go to Settings -> Technical -> IAP -> IAP Accounts
- Add the credentials for the Document Digitization service
- Go to the Expenses app
- Change the user's language to French
- Import the expense image from the ticket
- Open the newly created Expense and click Refresh

Before the fix, the title should stay `Dépense sans titre...` If it's not the case, try a second import, it works times to times

opw-6103935

Description of the issue/feature this PR addresses:
  In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the
  front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS
  1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match.

  Current behavior before PR:
  _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator
  popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line.

  Desired behavior after PR is merged:
  The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts
  in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a
  foreign-currency pricelist.

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

Forward-Port-Of: odoo/odoo#269386

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

PR very similar to https://github.com/odoo/odoo/pull/263236 but here 
on the SO side instead of PO
**Problem:**
account move created by stock valuation layer
does not take analytic account from SO

**Steps to reproduce:**
- make sure you have at least one analytic account
- create a storable product with categ standard automated
- set a positive cost and a positive on hand quantity
- create a SO for 1 quantity 
- on the SO line of the product, in the analytic distribution 
column (might need to be unfiltered) set an analytic account
- confirm SO and validate delivery
- 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 sale order line like it's the case for the invoice.

For the analytic distribution of the Invoice, the selection is : 
1) take analytic distribution from SO 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 invoice

**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 sale_line_ids
no analytic distribution will be returned
https://github.com/odoo/odoo/blob/261b15953ca89657644f52d1cb9ecda6e3b686c5/addons/sale/models/account_move_line.py#L41-L46

opw-6022695

Forward-Port-Of: odoo/odoo#268866
Forward-Port-Of: odoo/odoo#268031

Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
    * Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project

Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.

Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66

During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441

`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12

In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
    * On read: Get the value from `self.partner_id.name`
    * On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.

So, the partner record itself was renamed. Every record that references a partner now sees the new name

Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
    * The existing partner is untouched
    * All other tasks and the sales order keep their correct customer

opw-6206080

Forward-Port-Of: odoo/odoo#264738