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

When the user installs the ``crm`` module and later uninstalls it,
a traceback is generated.

Steps to reproduce the error:
- Install ``crm`` module and then uninstall it

Traceback:
```py
IndexError: list index out of range
```

When the tour service starts, it retrieves the last tour stored in
localStorage at [1] which is ``crm_tour``.

In commit [2], ``options.fromDB`` was removed. Because of this,
the condition is bypassed and ``get_tour_json_by_name`` called for ``crm_tour`` at [3],
which does not exist in the database. It then calls
``_get_tour_json``, which leads to the above traceback from the following line. https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/models/tour.py#L48-L53

[1]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_state.js#L13-L15
[2]: https://github.com/odoo/odoo/commit/7e5fdec2e600feb0fbfc663107175b75ec842fea
[3]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_service.js#L163-L164

sentry-7473093931

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

**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

Steps to reproduce:
1. Create a new partner with any level.
2. Click on the Go to Website button and publish it.
3. Now go to the /partners page and activate editor.
4. Now try to edit the short description of the partner.

Current behavior:
The short description is not editable in the frontend. This is due to the changes made in the editor, before the changes, the o_editable class was getting added additional properties to give it a minimum height and width, along with making it an inline-block element.

But now, these properties has been removed, which is causing an issue for users adding new partners and trying to edit the short description in the website.

Solution:
We brought back the crm_partner_assign.scss and added the properties back to the o-editable element inside our specific partner short description. Also added a placeholder to the short description to make the interaction more intuitive for users.

opw-5955922

Forward-Port-Of: odoo/odoo#266211
Forward-Port-Of: odoo/odoo#253097

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

Before this commit:
---

- Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name.
- If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44).
- However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`.
- As a result, nothing was shown when `summary` was empty, even though `display_name` was set.



Steps to reproduce:
---

- Create an activity in chatter
- Remove the default summary if set.
- Observer the title.

https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045


After this commit:
---

- Added `display_name` to `_to_store` along with `summary`.
- Chatter activity now correctly falls back to `display_name`.
- Users can now see the correct activity label in chatter.




OPW: 6212976



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

Forward-Port-Of: odoo/odoo#267555
Forward-Port-Of: odoo/odoo#266706

**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

**Steps to Reproduce**

1. Open a database in version 19.2 with demo data.
2. Install the `website` and `im_livechat` modules.
3. Login with another user who has access to the Website application but does not have access to the Live Chat application.
4. Navigate to: **Website → Reporting → Visitors**
5. An `AccessError` is raised with the traceback below.

**Issue:**
The traceback is caused by the following [commit](https://github.com/odoo/odoo/pull/240778/changes#diff-580c2ced97a218f926605037b31c4fd2d01253eb1b4f290038f251f9ef31be3b) introduced in v19.2.
In this commit, a new [computed field](https://github.com/odoo-dev/odoo/blob/381aede4fde0f871b51df41911c28be3153cd489/addons/website_livechat/models/website_visitor.py#L32) `current_livechat_agent_ids` was added on `website.visitor`.
Inside this compute, data from `im_livechat.channel.member.history` is accessed using `_read_group`.
However, `im_livechat.channel.member.history` is only accessible to users belonging to the following group: `im_livechat.im_livechat_group_user`
At the same time, the Website Visitors menu is accessible to normal Website users through the Website module [ACLs](https://github.com/odoo/odoo/blob/006a6a1cc6e50bd8b328d0cabb7abbcf610e34bb/addons/website/security/ir.model.access.csv#L30)
The issue occurs because the same `website.visitor` views/actions are reused from multiple menus (Website, Social Marketing, Live Chat), but the compute method assumes that the current user has Live Chat access.
As a result, when a user without Live Chat permissions opens: **Website → Reporting → Visitors**
the compute of `current_livechat_agent_ids` triggers an `AccessError`.

**Solution:**
To fix this issue, a group access added on the field `current_livechat_agent_ids`

**Traceback:**

```python
File "/home/odoo/src/odoo/saas-19.2/addons/
website_livechat/models/website_visitor.py", line 32, in
 _compute_current_livechat_agent_ids
self.env["im_livechat.channel.member.history"]._read_group(
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 1933, in
_read_group
    self.browse().check_access('read')
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
    raise result[1]()
odoo.exceptions.AccessError: You are not allowed to access
'Keep the channel member history' (im_livechat.channel.member.history) records.

This operation is allowed for the following groups:
    - Live Chat/User

Contact your administrator to request access if necessary.
```
opw : 6169395
upg : 4286153, 4286493, 4283345
tbg : 2676

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

Forward-Port-Of: odoo/odoo#265534

**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

# How to reproduce
- Install the Accounting module
- In the settings, enable "Sales Credit Limit"
- Remove the Accounting access rights of the current user
- Try to create a new user

# The issue
An access error is raised on the field `credit_limit`

# Cause
Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518

When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users`  inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error.

# Proposed solution
Back port of this commit : https://github.com/odoo/odoo/pull/267193

Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150

opw-6240494

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

Forward-Port-Of: odoo/odoo#268303
Forward-Port-Of: odoo/odoo#268039

**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

Issue:
----------------------------------------
In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes.

Steps to reproduce:
----------------------------------------
- Install Project and Timesheet
- Switch the user language to Spanish
- Open a task, in the "Timesheet" page, create a new line
- Input "0,5" as duration

Cause:
----------------------------------------
In the parser, the value is transformed according to the language decimal point and thousands separator:

```js
value = value
    .replaceAll(localization.decimalPoint, ".")
    .replaceAll(localization.thousandsSep, "");
```

In Spanish `decimalPoint` is "," and `thousandsSep` is ".". So the first `replaceAll()` changes "0,5" into "0.5", then the second one deletes the point.

Solution:
----------------------------------------
We need to invert the two `replaceAll()`.
As the `thousandsSep` is just removed, this will not create a new issue in another language.

opw-6263523

Forward-Port-Of: odoo/odoo#268461