_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered.

**Steps to Reproduce:**
- Install Sales module
- Create a Quotation
- Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**.

**Error:**
`TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()`
 `missing 1 required positional argument: 'product_template_id'`

**Root Cause:**
When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered.

[1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13

**Solution:**
This commit prevents the error by correcting `depends` on the field
`is_configurable_product`, which will ensure that edit button will be only
present if the configurable product is selected.

Sentry-5741581459, 6925770690

\* : website, web_editor, html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#222171

**Issue**
When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch.
Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view

**Steps to Reproduce**
1. Create and confirm a subscription with a recurring product (e.g., Car Leasing)
2. Generate and post the invoice for the subscription
3. Add a new product line to the subscription (e.g., Office Cleaning Service)
4. Delete the original invoiced line (Car Leasing)
5. Attempt to create an invoice for the new product line
→ Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category."
(https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view)

**Root Cause**
Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation.

**Fix**
Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation.

This commit fixes various issues when using Viva Wallet, including the following:
- When two Viva Wallet terminals had a payment in process at the same time in the same POS, one of the payments would fail on Odoo even when it succeeded on the terminal.
- When a previous Viva Wallet payment was stuck (never completed or failed), trying to make a new payment would mistakenly affect that previous order instead of the new order.
- When refreshing the page during a payment, it becomes stuck and never confirms or fails.

To fix these issues, there are two main changes:
1. Stop using the `getPendingPaymentLine` method to retrieve the Viva Wallet payment line. This method is flawed as it assumes there is only one pending payment at a time.
2. Store the Viva session ID for a payment in the payment line's UI state, instead of on the plain JS object. This allows it to persist after a refresh.

opw-5226966
opw-5248178

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

This error occurs while entering the barcode number.

Steps to reproduce:
---
- Install `stock_barcode` module(without demo)
- Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`
- Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply

Traceback:
---
`KeyError: 'rule'` (with GS1 Nomenclature)
`AttributeError: 'list' object has no attribute 'get'`  (without GS1 Nomenclature)

At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that.

This commit ensures that the correct keys are passed in the result dictionary.

[1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189

[commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60

sentry-6992944243

[FIX] purchase_mrp, sale_purchase_stock: track kit bom when receiving without pull rule

Problem:
If an inventory workflow is completed without any pull rules (only Push or Buy), then `bom_line_id` is never set on the sale order line. The result has two primary impacts: `qty_received` will not be updated upon final transfer, and the COGS line on the invoice will be calculated using the incorrect method, with an incorrect result.

Solution:
Upon confirming a Purchase Order, when the picking is being created, we will try to assign the `bom_line_id` on the Sale Order Line if:
	1. The PO is attached to a Sale Order
	2. The SO line is for the kit
	3. The product on the PO line is component of the BOM for that kit
With the `bom_line_id` assigned on the SO line, `qty_received` will be calculated correctly for kits, and COGS lines on the generated invoice will also be calculated correctly based on the kit.

Steps to Replicate (Runbot 18)
- 2-step receipt, 2-step delivery
- Cross-Dock enabled
- Kit item, fifo auto
	- No routes enabled on kit
	- Two components, fifo auto
		- Enable Buy and Cross-Dock routes
		- Set a vendor and non-zero price

1. Create a sale order for the kit and sell for non-zero price, confirm
2. Confirm the PO
3. Validate the pickings
	1. Receipt
	2. Cross-Dock
	3. Delivery
4. Go back to the sale order, note the first issue of 0 quantity delivered
5. Create an Invoice
6. Confirm the invoice, note the second issue of the COGS lines being triple the total purchase price

opw-5139590

When creating a new allocation,
selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend,
Flush accrual_plan_id when changing the allocation type.

### **Steps to reproduce:**

1. Create a test database (version 17 or later).
2. Install the `hr_holidays` module.
3. In the Time Off module, navigate to Allocations.
4. Create a new allocation.
5. Select "Accrual Allocation" and assign an accrual plan.
6. Change the allocation type back to "Regular Allocation" and save.
7. Verify the accrual plan is registered in the backend.

**Note:** The accrual_plan_id field is displayed for visibility.

**Before Fix:**
<img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" />
<img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" />

```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18;
 id |   private_name    | allocation_type | accrual_plan_id 
----+-------------------+-----------------+-----------------
 18 | Before allocation | regular         |               1
(1 row)
```

**After Fix:**
<img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" />
<img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" />


```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19;
 id |   private_name   | allocation_type | accrual_plan_id 
----+------------------+-----------------+-----------------
 19 | after allocation | regular         |                
(1 row)
```

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#231253

Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.

**Error:**
    `ProgrammingError: can't adapt type 'res.partner'`

This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or 
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes 
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID, 
when the system tries to browse the partner by this record [3], the error is raised.

This commit ensures that when writing the parent_id of the partner, the actual ID is used instead 
of the record.

[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386

[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53

[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801

sentry-6831922000

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

_______________________________________

On barcode, when an item isn't picked, when clicking on quality checks,
 the quality check for the unpicked item will still show.

1. Go to Quality and create a control point by clicking on Quality Control. Click on new, set a title and put 2 products in the field Product. In operation, select Receipt.
2. Go to Inventory and click Receipts.
3. Click New. Fill the Receive From field, and add 2 products. Set the demand field to 2 for example.
4. Click on Mark as Todo.
6. Go to Barcode. Click on Operations, the Receipts, and click on the latest Receipt you created.
7. For one product, click on the +2 button. For the other one, leave it at 0. Then, click on Quality Check.

Only the quality check for the item that has been picked should show.

Both quality checks show.

The behavior of the code is different when we perform the operations in backend compared to when we perform them in barcode. Indeed, for the regular flow in Inventory, in ```check_quality()```, we also retrieve the checks linked to a move line that hasn't been picked: https://github.com/odoo/enterprise/blob/c09a5cbc2450ec32b0ad3985fa2d4e5e2fcd3d71/quality_control/models/stock_picking.py#L44-L58 Which isn't the intended flow for barcode. Thus, we have to change this behavior and take into account the environment. __
opw-5010764

### Steps to reproduce:
	- Create a sale order with a SOL and an optional product
	- Preview the sale order and add the optional product to the order
	- Go back to edit mode and change the pricelist
	- Click on 'Update Prices'
	- Notice the optional product price won't change

### Cause:
When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation.

If sale_subscription is installed we will set the product's prices to 0 

https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 

so the price of the 'Optional product' SOL will change but will be equal to 0

### Fix:
An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed

opw-5058609

Forward-Port-Of: odoo/odoo#230053

**Issue:**
As a user without "Administration / Settings" access, it is not possible to revoke SEPA Mandates that have been used to pay invoices through the customer portal.

**Steps to Reproduce:**
- Enable SEPA Direct Debit payment provider in Test Mode
- Create a mandate for a customer w/ valid IBAN
- Create an invoice for that customer and post it
- Action > Generate a Payment Link, open this in an incognito window
- Pay using SEPA Direct Debit
- Call `_set_done()` on the payment.transaction
- Try to revoke the mandate as a non-admin with "Accounting / Billing"

-> Access Error, can't modify payment.token

**Cause:**
- When SEPA Mandate is revoked, we check for all associated payment tokens (saved payment methods from SEPA Direct Debit payment provider) and deactivate them.
- The check in code isn't called with sudo, so it uses the current user access rights, but only admins can modify the payment tokens in any way.

**Solution:**
- Write to the `linked_tokens` with sudo so we can archive the tokens regardless of user access

opw-5136221

Forward-Port-Of: odoo/enterprise#99232

While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:

As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.

This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.

Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.

### Before this bug:

Sending a mail using `charset=cp-850` would generate a traceback.

Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"

This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable

Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```

Would generate:
```
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
    msg_dict = self.message_parse(message, save_original=save_original)
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
    msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
    content = part.get_content()
  File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
    return content_manager.get_content(self, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
    return self.get_handlers[maintype](msg, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
    return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```

### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias

OPW-5171501
OPW-5247486


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

Forward-Port-Of: odoo/odoo#235529