**Current behavior:**
In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category.

**Expected behavior:**
The attributes that do not have a positive count should disappear from the Search Panel.

**Steps to reproduce:**
1. On a blank database, create two products: 
        1.1 Product A, with category CA and attributes A1 and A2.
        1.2 Product B, with category CB and attributes B1 and B2.
3. Go to Sales Order, create a new one and open the product catalog
4. The left search Panel should display the categories CA and CB, and the attributes A1, A2, B1, and B2.
5. Check the category CB.
6. Attributes A1 and A2 are still present.

**Cause of the issue:**
The search Panel JS script is modified by the `product` model, to add the Attributes section. However, the attributes are not filtered based on the selected category, and are always displayed.

**Fix:**
- Add a filtering condition in the `product` model to only display the attributes that have a positive `count`.

![all_category](https://github.com/user-attachments/assets/2121ecbb-9bed-4d3c-9f5f-c4cf309350ff)
![fix_difference](https://github.com/user-attachments/assets/612e0eeb-09c5-47eb-948f-8c8be204f862)

opw-4516166

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

Forward-Port-Of: odoo/odoo#197116

This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure.

- Install the `eCommerce` module without demo data and with Indian localization.
- Install `Razorpay payment provider` and activate `developer mode`.
- Add `Key ID` and `Key Secret` in Razorpay payment `provider`.
- Set up webhook in Razorpay dashboard with a random `Webhook Secret`.
- Go to the `website`, add the product to the cart, and proceed to payment using
 `UPI`.`

`Error: 'bool' object has no attribute 'encode'`

This issue occurs because the Webhook Secret is missing, returning False and causing payment verification to fail.

This commit solves the error by handling missing `Webhook Secret` values by
logging a warning and skipping the signature check instead of returning a False.

Sentry: 6208134651

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

Forward-Port-Of: odoo/odoo#196125

**Current behavior:**
Changing the `delay` field on a `product.supplierinfo` then
looking at the replenishment report will not have updated the
qty fields of the orderpoint which were affected by the increase
in delay (delivery lead time in the 'Purchase' tab on Product
form).

**Expected behavior:**
The `qty_forecast` and `qty_to_order` fields update to reflect
moves which should be captured according to JiT forecasting.

**Steps to reproduce:**
1. Create some productA with a vendor that has some lead time

2. Create a sale order for that product, edit the sale order
`commitment_date` field
(Sale Order -> Other Info -> Delivery Date)
to some future date such that the delay would not necessitate
any replenishment at the current date
(i.e., today + delay + 1 day)

3. Create an orderpoint for the productA, see that the
`qty_to_order` is 0 -> this makes sense

4. Increase the delay for the vendor on productA enough that a
purchase order would be required to fulfill the sale order on
time

5. Go back to the replenishment report -> qty to order still 0

**Cause of the issue:**
`qty_to_order` is stored and computed, in this sequence none of
its dependencies are modified and so it remains 0 after `delay`
on the supplier info record is changed.

**Fix:**
Add `product_id.seller_ids.delay` to the dependency list of
`_compute_qty` (From 17.4+ `_compute_qty_to_order()` is OK)

opw-4333016

Forward-Port-Of: odoo/odoo#195657
Forward-Port-Of: odoo/odoo#189427

Steps to Reproduce:

* Go to Website --> Edit Mode.
* Drag and drop the form snippet.
* Click inside the submit button such that the entire label "Submit" is
  selected.
* Press the right arrow key.
* The website will become unresponsive.


**Changes made:**

Assign `previousSelection` with the following properties:
 `anchorNode: selection.anchorNode`
 `anchorOffset: selection.anchorOffset`
 `focusNode: selection.focusNode`
 `focusOffset: selection.focusOffset`

**Reason:**

The original code attempted to spread the Selection object into previousSelection using **{...selection}**, which is incorrect since **the Selection object is not iterable**. As a result, `previousSelection` was never updated correctly, potentially causing the while loop to run indefinitely.

This fix manually extracts key properties—anchorNode, anchorOffset, focusNode, and focusOffset—from the Selection object and stores them in a plain object. This ensures that previousSelection updates properly, allowing the `hasSelectionChanged` function to function as expected.

By implementing this change, we prevent infinite loops and ensure accurate selection tracking, improving the stability and functionality of the text editor.

task-4471656

Forward-Port-Of: odoo/odoo#197010
Forward-Port-Of: odoo/odoo#194061

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

### Issue:

The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are loaded using search methods that ignore archived records by default. This leads to the creation of a cache that do not contains records that are expected to be there and hence will lead to tracebacks.

### Steps to reproduce:

- In the settings enable "Multi-Step Routes"
- Inventory > Configuration > Warehouse Management > Locations
- Create a new location WH/Stock/Love and a children location WH/Stock/Love/Layer
- Create and confirm an internal transfer from WH/Stock to WH/Stock/Love for 1 unit of any storable product in stock
- Change the location dest of the move line to WH/Stock/Love/Layer.
- Archive the location WH/Stock/Love
- Open your internal transfer in the barcode App.
#### > Traceback: An error occured in the owl lifecycle... Record stock.location with id=... doesn't exist in the cache, it should return by the server at LazyBarcodeCache.getRecord.

### Cause of the issue:

When entering the barcode man component, a call of the `get_barcode_data` is launched to fetch and populate the barcode data's and data are added to the barcode lazy cache in order to retreive record values without additional rpc calls:
https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/main.js#L76-L93 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_model.js#L32-L34 For instance, when redering the picking template, the location dest id will be retreived from the cache:
https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/line.js#L7-L9 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_picking_model.js#L1077-L1079 The traceback occurs because the record was actually never added to the data's and hence never added to the cache because part of the `get_barcode_data` call is performed with searchs that ignore completely the archived records (unless the 'active_test' key is in the context): https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/models/stock_picking.py#L102-L106

opw-4423110

Forward-Port-Of: odoo/enterprise#78297