Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report.

## Steps to produce:
* Install mrp_account without demo data.
* Create a product with inventory tracking enabled.
* Create a BoM of type kit for that product.
* Add component products with a defined cost and on-hand quantity greater than 0 to the BoM.
* Recompute the kit product’s cost from its BoM on the product page.
* Go to Inventory > Reporting > Stock > Inventory at date > Confirm

## Observed Behavior:
Even though kits do not appear on stock valuation they still do appear the inventory history report.

**Why kits should not appear on inventory history**
For example, consider a kit product called 'Computer' that is composed of the following components:

| Product | Quantity | Cost |
|--------|--------|--------|
| CPU | 1 | $300 |
| Motherboard | 1 | $300 | 

The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value  at that particular date as $1,200, which is incorrect because it is counting both the kit and its components

## Root cause:
This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm.

At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear.

**Why doesn’t this issue occur in the normal stock view?** 
Because the domain is overridden at [2] to explicitly exclude kit products from the stock view.

However, the quantity history report does not apply this same domain override, so kit products continue to appear there.
[1]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]:
https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166

## Solution:
To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered.

This can be achieved by modifying and overriding the domain to explicitly exclude kit products.

This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835).


opw-6164547

Forward-Port-Of: odoo/odoo#262185

Steps to produce:
---
- Install the `Sales` module, enable `Variants` in settings.
- Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save.
- Create a sales order, add the product > configurator opens.
- Without saving, open and close the configurator repeatedly (using the pencil icon).

Issue:
---
-  Product price keeps increasing on every open.

Root cause:
---
- After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation.

Fix:
---
- Clone the array to avoid mutating the live `currentIds`.

[commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b

opw-6267273
---

**Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow.



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

Forward-Port-Of: odoo/odoo#267991

**Steps to reproduce:**
* Install the **l10n_es_edi_sii** module.
* Create a **Portuguese customer**.
* Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping.
* Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**).
* Go to **Accounting → Reporting → Tax Report → OSS Sales**.
* Export the **VAT Record Books (XLSX)** file and open it.

**Observed behavior:**
* The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17".
* The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17".

**Cause:**
* In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01".
* This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table.

**Fix:**
* Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`.
* For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise.
* For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise.

opw-6197141,6216485

Forward-Port-Of: odoo/enterprise#119467
Forward-Port-Of: odoo/enterprise#117236

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

  This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for  l10n_pl.bank.account.verification  was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ).

  ### Current behavior before PR:

  • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice:
  │  You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. 

  • This triggers a failure to write/compute the transient field  account.payment.register.l10n_pl_bank_verification_ids  during the payment wizard load, completely blocking billing  users from processing payments.

  ### Desired behavior after PR is merged:

  • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices.
  • The payment register wizard computes the  l10n_pl_bank_verification_ids  and displays warning banners regarding VAT verification without throwing security exceptions.
  • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group.

Closes #263938

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

Forward-Port-Of: odoo/odoo#267992

Issue 1: Assistant Rules inaccessible to standard users

Steps to Reproduce:

- Install sale_timesheet.
- Disable the "Billing Rate Indicators" setting.
- Log in as a user with only "Own Timesheets" access.
- Open the Timesheets app.

Current Behavior:
- The Configuration menu is completely hidden, making Assistant Rules inaccessible to the user.

Cause:

- When sale_timesheet is installed, the "All Timesheets" access restriction is inaccurately applied to the main Configuration parent menu rather than specifically targeting the Billing Rate child menus.
- The Configuration menu is blacklisted using a strict AND condition, requiring the user to have the Use Assistant group and hold a Timesheets Admin / Administrator / Technical Features role. This prevents standard timesheet users from configuring their own rules.

Fix:

- Remove the "All Timesheets" access restriction from the parent Configuration menu and apply it directly to the Billing Rate menus instead.
- Update the blacklisting logic to use an OR condition, ensuring the configuration menu is visible if a user has Admin access to timesheets or belongs to the Use Assistant group.

---

Issue 2: Unable to share rules with higher-level users

Steps to Reproduce:

- Create a user with "All Timesheets" access.
- Open the Timesheets app and navigate to Assistant Rules.
- Attempt to share any rule with the newly created user.

Current Behavior:
- The new user is missing from the dropdown selection list.

Cause:
- The domain on the user selection field filters based on explicitly assigned groups (using group_ids for "Own Timesheets" access). Users with higher-level access, such as "All Timesheets" or "Timesheets Admin", have this access implied rather than explicitly assigned, meaning it only registers in `all_group_ids`.

Fix:
- Update the field domain to evaluate `all_group_ids` instead of `group_ids`. This ensures users with implied group access are correctly populated in the dropdown list.

task-6236300

**Steps to reproduce:**
- create a new company A
- in the branch tab, create a new branch A for this company
- create a warehouse for the company A and a warehouse for 
the branch A
- from the company A, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From the branch A:
- create a storable product with standard perpetual category
- set a cost of 10
- confirm a PO for 10 and validate delivery
- navigate to 'inventory valuation'

Make sure the branch A is the main company, but 
both branch A and company A are selected: 
- click on generate entry
- click on the 'Other Info' tab

**Current behavior:**
The company of the account move is the parent company
(Company A)

**Expected behavior:**
It should be the branch A. 
(As it is the case if only branch A is selected when clicking 
on "Generate entry")
IAs a consequence, f you click on 'Inventory Valuation' on the 
top left to go back to the view, you will have an access error. 

**Cause of the issue:**
When computing the company_id on the account move, 
move.journal_id.company_id will be the parent company because 
the journal_id of the branch is the one of the parent company 
(by default).
So we will call _accessible_branches() on the parent company.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/addons/account/models/account_move.py#L878-L881
Inside __accessible_branches(), 'accessible' will be based on 
self.env.companies 
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L430-L439
(which is based on 'allowed_company_ids' in the context.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/environments.py#L266)
So the return value of __accessible_branches()
will be a list with 2 ids, the one of the parent 
company and the one of the branch. 
And we will use the first element of this list,
which will be the parent company_id, in _compute_company_id
to set the company of the account move.

**fix:**
When fetching the data for the inventory valuation view, 
only the data from the main company selected matters,
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

The idea of the fix is to do the same in action_close_stock_valuation
when creating the account move.
We already did something very similar in this PR
https://github.com/odoo/odoo/pull/262776 where we also 
modified the context in action_close_stock_valuation()
before calling _action_close_stock_valuation()
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/res_company.py#L56

opw-6144294

Forward-Port-Of: odoo/odoo#266776
Forward-Port-Of: odoo/odoo#263828

**Problem:**
Adding a single-value attribute to a product template that has variants with manually-set sales prices wipes those prices, resetting each variant back to the template's base list_price.

**Steps to reproduce:**
1. Create a template "Cable" with attribute Length [1m, 5m, 10m, 15m] (template list_price=1.0).
2. On each variant, manually set a unique Sales Price (10/20/30/40).
3. Add a single-value attribute (e.g. Brand=MELODIKA) to the template.
4. Observe variant Sales Prices.

**Current behavior:**
All four variant prices are reset to 1.0 (the template list_price). Variant ids are unchanged.

**Expected behavior:**
Variant prices remain at the manually-set values, since no variant is created or removed.

**Cause of the issue:**
In 19.x, product.product.lst_price is a stored compute with readonly=False, allowing per-variant overrides. The single-value branch of product.template._create_variant_ids writes
product_template_attribute_value_ids on each existing variant to attach the new attribute. That write invalidates the variant's price_extra (One2many depends), which in turn invalidates the stored lst_price compute. On the next flush, lst_price is recomputed as list_price + price_extra, overwriting the user override.

**Fix:**
Snapshot each variant's lst_price before the single-value-attribute write loop and restore the snapshot afterwards if the recompute changed it. This preserves user-set per-variant prices in the case the loop already exists to handle (single-value attribute that does not require recreating variants). Trade-off: if the single-value attribute itself carries a non-zero price_extra and the user had manual overrides, the extra will not auto-propagate to overridden variants. That is preferable to wiping the override entirely, which is the reported regression.

opw-6229147

Forward-Port-Of: odoo/odoo#265786

**Step to reproduce :**

1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.

**Issue :**

Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.

**Reason :**

The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix introduced in:
https://github.com/odoo/odoo/pull/248215

However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
    
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
    
**Solution:**
    
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.

opw-6210411

Forward-Port-Of: odoo/odoo#265740

**Steps to reproduce:**
- Install Documents app
- Upload a new pdf file
- Try to search the file with the 'Indexed Content' filter
- Search won't find the file even if the uploaded document contains the searched keyword/content

**Issue:**
After [1] (19.3+) the file upload process was reworked to avoid loading entire files into memory during
attachment creation (removed `'raw': file.read()`).

But this breaks the index content creation as it was using the `raw` field value during the create to
trigger the `_index` function in `_get_datas_related_values`.

Also, restoring the previous behavior for the indexation would undo the memory usage improvements that were made.

**Fix:**
Added the `_index` call in `_upload_file` after the attachment creation.

Also optimize the default text index to avoid reducing too much the memory improvements (but for now the other mimetypes can still be impacted by the type-specific `_index_*` and the external libraries performances).

[1] https://github.com/odoo/odoo/commit/6222dedaf89a595b6f499679c3f553aa081c46bd

opw-6232999

**Steps to reproduce:**
- Install Documents app
- Upload a new pdf file
- Try to search the file with the 'Indexed Content' filter
- Search won't find the file even if the uploaded document contains the searched keyword/content

**Issue:**
After [1] (19.3+) the file upload process was reworked to avoid loading entire files into memory during
attachment creation (removed `'raw': file.read()`).

But this breaks the index content creation as it was using the `raw` field value during the create to
trigger the `_index` function in `_get_datas_related_values`.

Also, restoring the previous behavior for the indexation would undo the memory usage improvements that were made.

**Fix:**
Added the `_index` call in `_upload_file` after the attachment creation.

Also optimize the default text index to avoid reducing too much the memory improvements (but for now the other mimetypes can still be impacted by the type-specific `_index_*` and the external libraries performances).

[1] https://github.com/odoo/odoo/commit/6222dedaf89a595b6f499679c3f553aa081c46bd

opw-6232999