**Issue**
In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities.

**Steps to reproduce**
- Create a subcontracting BOM of a final product using 1 component product
- Create a PO of the final product for a quantity of 10 and confirm it
- Modify the BOM to use 2 component products instead
- Go to the receipt of the PO and modify the quantity to 2 and validate it
- Click on the move line of the receipt -> The displayed quantity is 10 instead of 2

**Cause**
Setting the quantity triggers this line:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 
which calls:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107

Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89

And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146

**Solution**
Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies.

opw-5493577

Forward-Port-Of: odoo/odoo#246433
Forward-Port-Of: odoo/odoo#245065

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/a906c68b8e [REL] 18.3.35 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7d959d419d [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311)
https://github.com/odoo/o-spreadsheet/commit/addf98c28c [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/17e5af05f7 [FIX] tests: fix network serialization in mock [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/630faa62a2 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007)
https://github.com/odoo/o-spreadsheet/commit/e5af7c65d3 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Steps to reproduce:
-------------------
1. Install `l10n_in` and `l10n_in_hr_holidays`
2. Switch to an Indian company
3. Create a user and related employee without Time Off rights
4. Log in with the new user and create a past time off
5. Approve the time off as an time off manager/admin
6. Open the validated time off record as the employee

Issue:
------
Opening a validated time off raises the following UserError:
 ```python
You must have manager rights to modify/validate a time off that already begun.
```

Cause:
------
The `_get_durations` method in `l10n_in_hr_holidays` was updating the
`l10n_in_contains_sandwich_leaves` field every time it was executed.

When a user opened a validated time off record, this triggered a `write()` operation. Since non-manager users are not allowed to write on already started validated leaves, this caused a [UserError](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/hr_holidays/models/hr_leave.py#L793-L798)

The field `l10n_in_contains_sandwich_leaves` does not need to be updated
when `l10n_in_is_sandwich_leave` is False.
See [[1]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L156-L157) & [[2]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L62)

And this [part of the code](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L160-L173) is responsible to update `l10n_in_contains_sandwich_leaves` value.

**NOTE:**
Opening future validated time off records as a non-manager user triggers
`AccessError` as it is not allowed to update the validated time off record.

Solution:
---------
Ensure that `l10n_in_contains_sandwich_leaves` is updated
only when `indian_leaves` is applicable.

opw-5373055





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

Forward-Port-Of: odoo/odoo#240056

Issue:
-------
When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor.
for ex: `#snippet-anchor` in the `Button URL` field in the settings.

Cause:
--------
This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place.

Solution:
------------
To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on.
This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside.

Steps to reproduce:
-----------------------
1. Create a db in version 18.3 with website_sale installed.
2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings.
3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button.
4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings.
5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet.

Ref PR:
----------
https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399

Attachments:
-----------------
**Before Fix:**
[vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0)


**After Fix**:
[vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5)


- OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517)

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

Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps:
1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text
2. In one of the middle lines, delete one character --> undo --> add a new character
3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field
4. TraceBack: IndexSizeError: The index is not in the allowed range.

After this commit: we use the range of the DOM selection to set the
offsets of activeSelection. If the DOM selection is too wrong to be
corrected, e.g. the selection's anchor node isn't the same with range's
start container (or end container if direction is right to left), we do
not set new activeSelection but just return the previous activeSelection

task-5428788


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

Forward-Port-Of: odoo/odoo#246056

When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated.

### Steps to reproduce:

* Create a product A with variants of type never
* Create a sales order with two product A and confirm it
* Go on the delivery (don't validate it) and create a delivery slip
-> Issue, the name of the product appears twice.
* Reduce the quantity of product delivered to one
* Confirm and create a backorder
* Print the deliveryslip
-> Issue, the name of the product appears twice in the backorder section

### Observation:

When confirming the SO:
It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant:
https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300
This information is added to the picking_description (for which the fallback value is the product name):
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340
When printing the delivery_slip, it uses description_picking (and attempts to filter out the name):
https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74
However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name.

The same issue is present here :
https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180

opw-5153222

Forward-Port-Of: odoo/odoo#239693

*= quality_control, quality_mrp_workorder, mrp_workorder

Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown.

**Steps to produce:**
* Install `Quality` and `Manufacturing` with demo data
* Go to MRP > Configuration > Operations > Manual Assembly
* Create a pass/fail quality point with a failure message
* Create and confirm an MO for `Table Top`
* Go to Shop Floor > Activate work centers if inactive > Manual Assembly
* Fail the assembly using the quick-action button

Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing)

**Observed Behavior:**
* No failure message is displayed when the quality check is failed.

**Root cause:**
* This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears.

**Solution:**
* Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions.


**Before:**
<img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" />

**After:**
<img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" />


[1]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 
[2]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 
[3]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 
[4]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 
[5]:
https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161

opw-5403465

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810