**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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

Forward-Port-Of: odoo/odoo#259272
Forward-Port-Of: odoo/odoo#257211

[FIX] website: translate links inline on media replacement
    
    On the website builder, files added through the `/file` command would go
    through the domPlugin `insert` method, which would call
    `before_insert_processors` and apply `.o_translate_inline` as expected.
    But there is another flow to add a document on the page: replace an
    image (or video, or icon), then select the "Documents" tab and upload
    a file. With this flow, `insert` is not called, so we have to add the
    class through some other resource.
    
[FIX] html_editor: target documents with right class
    
    The class `.o_image` was still associated with documents (in the context
    of the file selector) and the expected tag of a document was `A`, in
    spite of it not being true in `html_editor` since the introduction of
    the file box in [1].
    
    This has also been updated in the website builder since the introduction
    of the `html_builder` module in 18.4, which swapped uses of `web_editor`
    components for `html_editor`.
    
    As a side-effect, in website, a double click on a file did not open the
    media dialog on the "document" tab, unlike other media (images, videos,
    icons). In such a case, the file was also not shown as already selected
    in the media dialog (because it targetted the wrong tag name). Both of
    those behaviors were lost as we used the new file box design in 18.4.
    
    [1]: https://github.com/odoo/odoo/commit/7f9afa21dffba2f74f9fb8a68809db4af6c7c225
    
task-5876278

### **Description of the issue/feature this PR addresses:**

**Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location

**Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location

opw-6032018

### **Current behavior before PR:** 
When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected.

### **Desired behavior after PR is merged:** 
The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes.




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

Forward-Port-Of: odoo/odoo#256725
Forward-Port-Of: odoo/odoo#254527

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.

**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.

- This leads to runtime issues such as:
    - Cannot convert field to SQL because it is not stored
    - Failures in search, domains, and reporting
    - Inconsistent behavior depending on usage context

- Currently, no validation prevents users from configuring such invalid related fields.

**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.

- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.

This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#102109
Forward-Port-Of: odoo/enterprise#98571