**Step to reproduce:**
- configure pos for global discount from settings
- start pos
- select product A and add a discount line (product A must have a cost price)
- confirm it.
- refund the same order.
- go to backend and open refunded order from `orders` menu

**Observation:**
- the margin percentage is > 100

**Cause:**
- After  https://github.com/odoo/odoo/commit/9538698f13d5763b49b00f4c06a1a2afc0d6b39e it has been decided to keep order sign regardless if it is refund
or normal order

**Fix:**
- Adapt `_compute_margin` to include signs based on order is refund or not

**Before**
<img width="1151" height="228" alt="image" src="https://github.com/user-attachments/assets/2a1760ad-7ad8-4b64-9d22-cf7cff98c90d" />

<img width="1144" height="198" alt="image" src="https://github.com/user-attachments/assets/8d2d4aff-1293-4906-b79b-518ca22317db" />

After
<img width="1144" height="253" alt="image" src="https://github.com/user-attachments/assets/ec1d4add-d93b-4490-86ad-f5f5d24de9c2" />

<img width="1170" height="244" alt="image" src="https://github.com/user-attachments/assets/c3ce5b6e-a572-4f85-9bf2-f651574ce124" />


opw-5362912


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

Forward-Port-Of: odoo/odoo#238093

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

For the `Türkiye` localization, sending an invoice by email with a recipient bank causes an error.

Steps to reproduce:
1) Install `accountant` and `l10n_tr_nilvera_einvoice` modules with demo data. 
2) Switch to TR Company.
3) Create a customer with country set to `Türkiye`.
4) Open the TR company contact and on the Accounting page edit an existing bank
   account, add a new bank (e.g., 'Test-Bank'), and set `Send Money` to
   `Trusted`.
5) Create an invoice for the customer, confirm it, and send it by email.

ref video: https://drive.google.com/file/d/1OoUzJ-Dr2uuy4yk9P-CKUS0L6OSgeyJ3/view?usp=sharing

Error:
KeyError: 'country_id'

Root Cause:
When sending the invoice, the system generates the invoice XML. In the method `_get_address_node` (see [1]), there is a special case to determine the correct country for `res.bank`. However, when `vals['partner']` is a `res.bank` record, no `model` is provided in `vals`, so it defaults to `res.partner`. The code then attempts to access `partner['country_id']`, which does not exist on `res.bank`, raising the error.

FIX:
Ensure the `model` is set to `res.bank` when `vals['partner']` is a `res.bank` record, ensuring the correct country value is used.

[1]- https://github.com/odoo/odoo/blob/0190bb7faca1dd5ce38dfdacbb8fa446f06d59a3/addons/l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py#L165-L181

opw-5103598

Forward-Port-Of: odoo/odoo#240715
Forward-Port-Of: odoo/odoo#239218

Step to reproduce:
- start pos and finalize a order with product A
- go backend
- Archive product A
- start the pos again
- try to refund the order

Observation:
- Blank page with traceback in console

```
Caused by: TypeError: Cannot read properties of undefined (reading 'filter')
at __exports.getOrderChanges
at Proxy.getOrderChanges
```


Cause:
- until now `product.template` model is looked for filter after a reload
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295
 and not `product.product`, this makes `product_id` available but 
`product_tmpl_id` undefined, causing inconsistency

Fix:
- we add `product.product` in `cleanupModels` for data to in sync with backend 

opw-5237961

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

Forward-Port-Of: odoo/odoo#240424
Forward-Port-Of: odoo/odoo#238514

The link between purchase order and a repair order break at when the PO is confirmed.

### Steps to reproduce:
* Install the Repair and Purchase modules
* Activate multi-steps routes
* Unarchive the MTO route
* Create a product with the MTO route enabled
* Create a Repair
* On the Repair Order, in part add:
	- type : ADD
	- product : mto product
* Save the RO
* Go to Purchase Order
* Confirm the PO
-> Issue Smart link between PO and RO broken.

### Observation:
The smart link is defined on:
RO -> PO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17

When we confirm the PO, from the picking information it will create new moves:
https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298

To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365

### Origin:
In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5:
"`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`."
This breaks the link between PO <-> RO to maybe merge the move in the future.

This issue is not present in 19.0 since it was solve in this commit :
https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a

### About the fix:
The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location.

opw-5121816

Forward-Port-Of: odoo/odoo#237996
Forward-Port-Of: odoo/odoo#232999

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

Steps to reproduce:
=======
1. Go to /shop in edit mode.
2. Change the Product Design.
3. Switch to the "Blocks" tab (so the "Style" tab is not visible).
4. Click on "Save".

Before this commit:
======
The selected Product Design was not saved.

After this commit:
======
The Product Design is now always saved correctly, even if the `ProductsDesignPanel` component has been unmounted.

Technical reason:
=======
The save behavior depended on whether the
`ProductsDesignPanel` component was still mounted at the moment of saving. If it was not alive, changes were lost.

Solution:
=====
We no longer depend on the component being alive. When the Product Design or the Gap is modified, we mark the product list with the `o_dirty_product_design_list` class. On save, we look for elements with this class, retrieve their modified data, and apply the changes.

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

Steps to reproduce:
1- Create new appraisal
2- Confirm appraisal
3- Edit employee and manager feedbacks
4- Set the final rating for the appraisal
5- Mark appraisal as done
6- Reopen appraisal

Issue:
The feedbacks of both the employee and manager are reset to the default template. They should be unchanged.

Cause:
Both the reopen and reset buttons used to call the the same action "action_back" which would set the state of the appraisal to "1_new", there is a compute that is triggered by the change in state which updates the appraisal's department_id which in turn triggers two other computes for the employee and manager feedbacks, those computes have a condition that if the state of the appraisal is '1_new', then the feedbacks should be reset to the templates.

Fix:
Make each button call its own action and make the reopen action set the state to '2_pending' instead of '1_new'. Furthermore make the reset action also reset the final rating for the appraisal.

Task-5411661

Forward-Port-Of: odoo/enterprise#102021

Two related overlay reposition issues are solved separately out of iframe and in the iframe.

**Commit 1:**
[FIX] html_editor: avoid wrong range after insert and popover reposition

Before this commit: The link popover is repositioned at the beginning of the
text when editing url. When insert, we first delete the non-collapsed selection,
then we split the text node by splitTextNode at the collapsed selection. However,
splitTextNode resets the text node's value by its substring, which breaks the
range of the collapsed selection. This range is stored and used to reposition
the overlay when the selection is not in the editable.

Reproduction:
1. selection some text, create a link
2. go the the url field and type something
3. the popover is replaced to the beginning of the text.

After this commit: we use dom function splitText to split the text only when we
need to, e.g. when the currently selection's offset isn't at the beginning or
the end of the text node. The dom function keeps the range properly maintained
after splitting.

However, there is a limitation case from how we create the link on selection,
how the browser manages the selection's range and how the overlay reacts to it.

The limitation case is when the selection is inside one text node and selecting
the whole text node of the range's startContainer (which is the same with
endContainer). When the link is created, we do extractContent on the selection's
range, put it in the link and insert the link at the collapsed selection. During
this process, the browser loses the range's start/end container which leads to
invalid start/end container.

For this range isn't valid case, it triggers the overlay plugin's special
handler which inserts one shadow caret (which is after the inserted link) and
uses it to calculate the position. Because the shadow caret is inserted by the
cloned collapsed range, we can't really have enough context from the range
(about where to re-place the caret) to manipulate the position.


**Commit2:**
[FIX] html_editor: pass selection data to overlay to avoid reposition in iframe

Before this commit: the overlay plugin uses the editable's document's selection
to check if the current selection is in the editable. It works when there's no
iframe, as the overlays are part of the document. However in an iframe's
editable zone, e.g. the website editing zone, the overlays are not under the
iframe document but under the outer window's document. When checking iframe
document's selection, it cannot detect the selection in the overlay, which gives
a wrong "inEditable" value.

After this commit: we pass the getSelectionData to the overlay so it can use the
existing currentSelectionIsInEditable

task-5184799


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

Forward-Port-Of: odoo/odoo#240796
Forward-Port-Of: odoo/odoo#237759

*: stock_barcode

Before this commit:
=======================
When accessing a manufacturing order via Barcode in `dark mode`, the producing bar of the finished product is difficult to read due to poor colour contrast.

Steps to reproduce:
=======================
1. Install the `mrp` module.
2. Switch to dark mode.
3. Open any manufacturing order using Barcode.
4. Observe the producing bar for the finished product.

- The text on the producing bar is hard to read because the colour of text does not provide sufficient contrast.

- Additionally, for products tracked by `lot or serial number`,  when the same product is added multiple times, the barcode view groups these entries into a single grouped line, causing the same visibility issue in both MO and normal `picking/transfer` operations.

Cause of the Issue:
=======================
In dark mode, both the text and background colour of the producing bar are light, resulting in low colour contrast and making the text difficult to read. Additionally, the `text-muted` class applied to the `units of measure (UoM)` further reduces readability.

After this commit:
=======================
Updated the text colour of producing bar and background colour of grouped lines to use a darker shade for better visibility in dark mode. Also, removed the `text-muted` class used on `UOM` to improve redability.

TaskID-5117608

Forward-Port-Of: odoo/enterprise#96718

The thread action 'view-contact' is somewhat like 'livechat-info', in that this action redirects to relevant info to the whatsapp user and livechat-info is a panel with all info on the visitor and more.

The position of both buttons were the total opposite in discuss app:
- 'livechat-info' was put as the 1st panel one before panels
- 'view-contact' was dead last.

There are differences, with 'livechat-info' being a panel and 'view-contact' a redirect button. However, each are important buttons for the type of conversation that justify them being in their own group right now. Since the buttons are mutually exclusive by the channel type, there's reason to have them share the same position.

This commit moves the position of 'view-contact' in discuss header thread actions to be the same as 'livechat-info', that is as the 1st action in the list. This makes its position consistent with livechat info, thus agents of live chat and whatsapp would appreciate the 2 button placement being consistent.

Task-5431313

<img width="1760" height="231" alt="Screenshot 2025-12-18 at 21 02 24" src="https://github.com/user-attachments/assets/ee2baf91-0d9a-49ca-91ac-a7781b33e57b" />

Forward-Port-Of: odoo/enterprise#102479

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
    - Create a new custom embedded action in project A
    - Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.

It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.

We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".

task-5269261

Forward-Port-Of: odoo/odoo#240711
Forward-Port-Of: odoo/odoo#237695

Since 19.0, routes are no longer displayed in the product form if no route outside from Buy/Manufacture are enabled, as those two now depend on whether there's a vendor/bom to be enabled for that product.

In the `setUpClass` however, without having the MTO route enabled by other means, there wouldn't be any route to display in the product form, resulting in a traceback at launch as the `route_ids` field would be invisible within the form.

Now we make sure the MTO route is always enabled (as it doesn't make sense to assign an archived route), which also forces the display of `route_ids` in the product form.
Also removes the assignation of the 'Manufacture' route on products, as its no longer necessary on product that have a 
bom.

In `purchase_mrp`, we just remove the usage of the Form for product
creation, as:
- The `routes` argument was never even used
- There was no point in creating these products through a form in the
  first place
This avoids having to enable an extra route for "nothing", just to have
`route_ids` appear in the form.

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

Forward-Port-Of: odoo/odoo#238394