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

**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`

**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
    ...
    model=self._name,
    notify_author=True,
    partner_ids=partner_ids,
    res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.

**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa

opw-5101510

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

Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

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

Forward-Port-Of: odoo/odoo#238040
Forward-Port-Of: odoo/odoo#236677

The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:
https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed.

#### Fix:

Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks.

#### runbot-226734

Forward-Port-Of: odoo/enterprise#101268
Forward-Port-Of: odoo/enterprise#100746

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

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

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

Forward-Port-Of: odoo/odoo#238040
Forward-Port-Of: odoo/odoo#236677

When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear.

**Steps to produce:**
- Install the `frontdesk` module.
- Ensure the database has at least two companies, each with a logo configured.
- `Enable multi-company` access (user has access to all companies).
- Open any Frontdesk station configuration and change the company to one different from the currently active company.
- Copy the kiosk URL and open it in an incognito/private window.
- The kiosk opens, but the company logo is missing.

**Issue:**
- Company logo not comes on frontdesk kiosk.

**Root cause:**
- When the kiosk URL is accessed, Odoo logs an `Access Denied by record rules`.
- This happens because the selected company on the station is not included in the `Public User’s companies`.
- As a result, the public user cannot read the company record, so the logo does not load.

**Solution:**
- Added an `onchange` on `company_id` to automatically include the selected
 company in the Public User’s `company_ids` if it is not already present.
- This ensures the kiosk always has access to correct company record and logo.
- Also added an XML-side fix to prevent an access error that occurs when
  a company is not activated and we attempt to select it in the company field.

**Before:**
<img width="500" height="500" alt="frontdesk_image_before" src="https://github.com/user-attachments/assets/b002ac6e-5271-4561-bf03-542a3feeefd1" />

**After:**
<img width="500" height="500" alt="frondesk_image_after" src="https://github.com/user-attachments/assets/7b5bffe4-ccbf-48f5-ad9c-d5e6d2e7678e" />

**opw-5138980**

Forward-Port-Of: odoo/enterprise#101534
Forward-Port-Of: odoo/enterprise#100300

step to reproduce:
- create a invoice and confirm it
- remove due date from it and save it 
- ensure the confirmed invoice do not payment term or due date
- open aged receivable report
- open this entry 
<img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" />


Observation:
- on clicking the entry, when redirected to list view, there are `0` records.

Issue:
- The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)`

https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226

- while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view
- This creates inconsistencies between two. 
https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394

opw-5237298

Forward-Port-Of: odoo/enterprise#99883

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

Forward-Port-Of: odoo/enterprise#98808

Steps to reproduce:
===================
1- Add a product & product variants
2- Add different photos for product & product variants 3- visit website shop
-> observe that the product image is set to the image of the first product variant

Cause:
======
The `product_tile` template defined a variable `variant` that defaulted to the first available variant if no specific variant was selected. The condition
https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/website_sale/views/product_tile_templates.xml#L62 subsequently used this default variant's image, bypassing the intended fallback to the product template's image.

Solution:
=========
Update the condition to check `product_variant` instead of `variant`. `product_variant` is only set when a specific variant is explicitly selected. This ensures the product template image is displayed by default, and the variant image is only shown when specifically requested.

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

## Versions
19.0+

## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".

## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
  - Look for a subscription service (ending with "SUB") and add it to cart;
  - Go to the cart and click the checkout button (automatically bypassing the addresses form);
  - Pay with Demo.
- Logout and sign in as admin user:
  - Go to Sales and open the latest SO (related to the test user):
    - Duplicate the SO and activate debug mode;
    - Open "Other Info" tab:
      - Change the subscription starting date for any date in the past;
      - Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
  - Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
    - Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
  - OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".

## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757

opw-5268156

Before this commit, seeing whether a livechat channel was joined or not in discuss app sidebar required to mouse-hover the category and seeing whether the action join or leave was present.

This is a problem because using livechat as an agent requires frequent join and leave. The mouse-hover is too subtle to know for sure whether the channel is joined or not, which is crucial for agent to not mistakenly forgetting to join the channel at the start of their shift or leaving at the end of their shift.

Also the mouse-hover technique on category shows the icon in muted state, and it's not easy to get at a quick glance since the icon are quite similar. The color is only shown on exact mouse-hover on the join/leave action.

In previous versions, these category actions were always displayed on the sidebar, but have their visibility reduced in 19.0 to declutter the discuss app sidebar visually. However this introduced this UX regression.

This commit fixes the issue by adding a small indicator on livechat categories that the user has joined as a tiny green dot. That way the discuss sidebar stays relatively simple visually but there's a quick and very easy indicator that the livechat channel has been joined. The agent can easily deduced the channel hasn't been joined by the non-presence of this indicator.

Before:
<img width="300" height="754" alt="Screenshot 2025-12-05 at 15 46 42" src="https://github.com/user-attachments/assets/f8940e69-779a-431d-ac2e-1b51fe36a2d5" />


After:
<img width="308" height="735" alt="Screenshot 2025-12-05 at 15 31 57" src="https://github.com/user-attachments/assets/586be26e-3ab3-4d00-ba13-7255c1b74ec4" />
<img width="353" height="741" alt="Screenshot 2025-12-05 at 15 31 32" src="https://github.com/user-attachments/assets/43a91144-07f7-474a-84d1-b8f3718a1ace" />

Step To Reproduce:
- install Project
- login with admin and open any Project settings, say Project 1.
- create a upload document activity for 'marc demo'
- ensure marc demo has 'User' access  for project
-  login with marc demo
- open same project (kanban card -> view)
- upload a document for the created activity

Observation:
-  Traceback

```
TypeError: Cannot destructure property 'id' of '(intermediate value)' as it
is undefined at Activity.onFileUploaded
```
Cause:
- upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model .
- as marc demo does not have write access to this model, no thread is returned
- so `NotFound()` is raised

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55

Fix:
- we check if selected user has appropriate rights or not for upload activity

opw-5160132


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

Forward-Port-Of: odoo/odoo#238533
Forward-Port-Of: odoo/odoo#234936

**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`

**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
    ...
    model=self._name,
    notify_author=True,
    partner_ids=partner_ids,
    res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.

**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa

opw-5101510

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

Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#101321
Forward-Port-Of: odoo/enterprise#99774

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

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

Forward-Port-Of: odoo/odoo#238040
Forward-Port-Of: odoo/odoo#236677

Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Currently, an error occurs when opening the `Trial Balance` report with 
Date Range disabled.

**Steps to reproduce:**
- Install the `account_reports` module and enable developer mode.
- Navigate to Accounting > Reporting > Trial Balance.
- Click the gear icon to open the configuration form.
- In the Options tab, disable `Date Range` and `save`.
- Try to open the `Trial Balance`.

**Error:**
`TypeError: '>' not supported between instances of 'NoneType' and 'str'`

**Cause:**
At [1], the code sets `no_impact_on_currency_table: True` only for the initial 
balance, but does not set it in the end balance method. In the method 
`_init_options_currency_table`, the condition for the end balance at [2]  is not 
satisfied, so the code below executes. When `already_present_period['from']` 
is `None` at [3], the comparison `>` between `None` and a `string`, 
causes the error.

**Fix:**
This commit prevents an error when opening the Trial Balance while the date 
range is disabled by ensuring that `no_impact_on_currency_table` is also set to 
`True` for the end balance at [4], similar to the behavior in `saas-18.2` at [5].

[1]:
https://github.com/odoo/enterprise/blob/cbc6e02ea1bc595b391f2f741f9f2f5d6e490eeb/account_reports/models/account_trial_balance_report.py#L160-L196

[2]:
https://github.com/odoo/enterprise/blob/cbc6e02ea1bc595b391f2f741f9f2f5d6e490eeb/account_reports/models/account_report.py#L1382-L1386

[3]:
https://github.com/odoo/enterprise/blob/cbc6e02ea1bc595b391f2f741f9f2f5d6e490eeb/account_reports/models/account_report.py#L1399

[4]:
https://github.com/odoo/enterprise/blob/cbc6e02ea1bc595b391f2f741f9f2f5d6e490eeb/account_reports/models/account_trial_balance_report.py#L180-L187

[5]:
https://github.com/odoo/enterprise/blob/d808ad3f6ff52632e00cf1a68de0e5270e52895d/account_reports/models/account_trial_balance_report.py#L37-L38

opw-5365462

Currently, an error occurs when user tries to create a new amazon account on a new company.

Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.

Error:
```
  File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
    'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```

Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].

Solution:
- Assigning the `location_id` if the `parent_location_data` exists.

[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210

[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204

[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214

sentry-7086464738

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#100940

### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.

### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed

### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
        line._origin.move_id.payment_reference and line._origin.move_id.ref
        and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
    ):
    line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.

The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so 
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).

### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.

The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.

Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.

### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted

We can have 2 and 3 but not with 1 afaik.

opw-5246917

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

This commit aims to fix two issues with the snippet modal in dark mode:
1. Streamline the background color accross browsers. Chrome takes into account the classes on the iframe for the background color but Firefox and Safari don't.
2. The text below the custom snippets is always black, regardless of the color scheme selected.

These 2 issues are fixed by using the color-scheme cookie value inside the snippet modal's iframe, adding as a meta tag and a custom class.

task-5095262

| Browser(s) | Before | After |
|--------|--------|--------|
| Firefox/Safari | <img width="1192" height="847" alt="image" src="https://github.com/user-attachments/assets/f38f4944-3379-4300-8ec7-78a73dcce7f1" /> | <img width="1174" height="828" alt="image" src="https://github.com/user-attachments/assets/06e93051-737e-4abe-b937-79ce9a4e0a33" /> |
| Chrome | <img width="1171" height="828" alt="image" src="https://github.com/user-attachments/assets/c5f1fcb4-eb55-4a26-83f5-e2c3c65ad0dd" /> | <img width="1174" height="833" alt="image" src="https://github.com/user-attachments/assets/c4066e4d-876c-455c-92eb-1ab0e115500c" /> | 



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

On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task

Steps to reproduce:
-------------------
* Create a product
	- Purchase: False
	- Sale    : True
* Create a fsm task
* Add products
* Go to the sale order
* Create the invoice (regular invoice)
* Go back to the task
* Go to the invoice using the invoices smart button
* Try to add your product
-> issue it's not possible.

Observation:
---------------
The domain of the search is not the same if we go from the sale order or from the task.

This is because the domain depend on the context and the context is not the same :
[Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141)

When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice":
[SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453)

Instead when using it on the task, the context does not have that element:

https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327

This will be calculate here in the js files:

[evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400)

opw-5135567

**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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