**Current behavior before PR:** Push notifications are shown even when the user is already viewing the same conversation in the Discuss app or in the ChatWindow. The Service Worker does not currently check whether the conversation is focused, leading to redundant and unnecessary notifications. **Desired behavior after PR is merged:** The Service Worker now intelligently checks the state of the Discuss and ChatWindow before displaying push notifications. Notifications are only shown

**Current behavior before PR:**

Push notifications are shown even when the user is already viewing the same
conversation in the Discuss app or in the ChatWindow. The Service Worker does
not currently check whether the conversation is focused, leading to redundant
and unnecessary notifications.

**Desired behavior after PR is merged:**

The Service Worker now intelligently checks the state of the Discuss and
ChatWindow before displaying push notifications. Notifications are only shown
when the user is not actively focused on the same conversation.
The updated logic ensures:

- Chat bubble minimized and tab focused → Show
- Chat window open, tab focused, but a conversation not focus → Suppress
- Chat window open, tab focused,  the conversation is focused → Suppress

This behavior is achieved by the Service Worker sending a message to the client
window to get the active thread and its focus status before deciding whether to
show a notification. This results in a cleaner user experience by avoiding
redundant alerts when they’re not needed.

task-[4582533](https://www.odoo.com/odoo/my-tasks/4582533)

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

Forward-Port-Of: odoo/odoo#206800

Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate `Multi-Step Routes` from Settings. - Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`. - Delete the `Buy` route record. - Create a new product without adding vendors or defining routes. - Click on the `Replenish` button. - Observe the error. `AttributeError: '

Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted.

Steps to produce:
- Install the `purchase_stock` module.
- Activate `Multi-Step Routes` from Settings.
- Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`.
- Delete the `Buy` route record.
- Create a new product without adding vendors or defining routes.
- Click on the `Replenish` button.
- Observe the error.

`AttributeError: 'NoneType' object has no attribute 'id'`

The issue occurs when attempting to access the `id` of the 'Buy' route `purchase_stock.route_warehouse0_buy` - [1], without verifying if it exists. If this route is missing, `self.env.ref(...)` returns `None` which leads to an `AttributeError`.

This commit resolves the issue by checking whether the `purchase_stock.route_warehouse0_buy` route exists before attempting to access its `id`. This prevents errors when the route is missing.

[1] - https://github.com/odoo/odoo/blob/58f4b01dda6ba2e67c21663399aab1c189f4a312/addons/purchase_stock/wizard/product_replenish.py#L108

Sentry-6275025957

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

Forward-Port-Of: odoo/odoo#196959

Required for fixes in 18.0+ branches Forward-Port-Of: odoo/odoo#212403

Required for fixes in 18.0+ branches

Forward-Port-Of: odoo/odoo#212403

**Current behavior before PR:** Link Preview is deletable for only editable messages **Desired behavior after PR is merged:** Link Preview will be deletable for all messages task-[4690326](https://www.odoo.com/odoo/all-tasks/4690326) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212464 Forward-Port-Of: odoo/odoo#208828

**Current behavior before PR:**

Link Preview is deletable for only editable messages

**Desired behavior after PR is merged:**

Link Preview will be deletable for all messages

task-[4690326](https://www.odoo.com/odoo/all-tasks/4690326)

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

Forward-Port-Of: odoo/odoo#212464
Forward-Port-Of: odoo/odoo#208828

## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". ## Expected behavior: The original SO picking should have been cancelled, i.e. in st

## Steps to reproduce:
- Create a SO from sales, and don't confirm it
- Enable 'Allow Ship Later' in PoS
- From PoS, settle the SO, with "Ship Later" option

## Observed behavior:
From the inventory app -> Delivery orders, we can see that 2 pickings
for this order have been created, one for the original SO order, and
another one for the PoS order. Both of them are in state 'confirmed',
i.e. "Ready".

## Expected behavior:
The original SO picking should have been cancelled, i.e. in state
'cancel', and only the PoS picking should be "Ready".

## Why that happens:
When settling the SO from PoS, that will create a new order from PoS
with its associated PoS picking. While doing that, we also confirm the
original SO [1], changing its state from 'draft' to 'sale', and that
will create a move and a picknig associated with that SO, both in state
'confirmed'.
So at this point, we're heading toward having 2 pickings, one from the
PoS order and the other from the SO, both in state 'confirmed', which
is undesired! What we want is having the SO's picking in state
'cancel', and the picking from PoS in state 'confirmed' (since we have
settled the order from PoS). To achieve this behavior, we check if the
quantity delivered on the SO (i.e. `so_line.qty_delivered`) compensates
for the qty that should be deliverd, i.e. for `so_line.product_uom_qty`
[2], and if so, we cancel the SO picking ([3], [4]).
However, if the order is "ship later", the `so_line.qty_delivered` will
be 0 at first, and will only get updated when the picking has indeed
being shipped [5], resulting in `new_qty` always being a positive
number, and hence also the `product_uom_qty` on the SO pikcing [6],
meanign that the SO picking will not qualify to be cancelled.

## The fix:
Now, in the computation of `new_qty`, we don't only compare
`so_line.product_uom_qty` with what quantity has indeed been delivered
(i.e. `so_line.qty_delivered`), but also with the quantity that is
expected to be delivered later (i.e. `get_expected_qty_to_ship_later`).

[1]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L74
[2]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L88
[3]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L95
[4]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L103-L104
[5]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/sale_order.py#L57
[6]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L94

opw-4375941
opw-4457592
opw-4490398
opw-4628515
opw-4599490

Forward-Port-Of: odoo/odoo#211453
Forward-Port-Of: odoo/odoo#197031

Steps to reproduce: - When the planning module is not installed and we click on employee avatar - This leads to a traceback, especially when the related employee data is available only in hr.employee.public or hr.employee. Cause: - The avatar card component was using a hardcoded model instead of dynamically using props.record.model. Although a custom get_avatar_card_data method was introduced to centralize data logic, it was not implemented on all relevant models (hr.employee,

Steps to reproduce:
- When the planning module is not installed and we click on employee avatar
- This leads to a traceback, especially when the related employee data is
  available only in hr.employee.public or hr.employee.

Cause:
- The avatar card component was using a hardcoded model instead of dynamically
  using props.record.model.

 Although a custom get_avatar_card_data method was introduced to centralize data
 logic, it was not implemented on all relevant models (hr.employee,
 hr.employee.public), which caused traceback in  certain setups.

Solution:
- Replaced the hardcoded model with props.record.model to dynamically
  resolve the model.
- Added the get_avatar_card_data method to hr.employee.base to ensure
  compatibility.

Ensured the logic works correctly even when the planning module is not installed.

Follow-up to:
- Commit : https://github.com/odoo/odoo/pull/187171 https://github.com/odoo/enterprise/pull/75121
- prevent component destruction which moved avatar card data fetching into a parent method to avoid lifecycle issues.

Related task-4210513
task - 4777570

Forward-Port-Of: odoo/odoo#210027

Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session). task-id: 4805617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211403

Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session).

task-id: 4805617



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

Forward-Port-Of: odoo/odoo#211403

**Before this PR:** The button label in the popup does not update when a user tries to edit a review. **Technical**- The button label updates only during the widget initialization, as it is handled in the willStart function. https://tinyurl.com/2derk498 **After this PR:** The button label in the popup correctly updates to 'Update Review' when a user edits a review. **Task**-4677251 Forward-Port-Of: odoo/odoo#211417

**Before this PR:**
The button label in the popup does not update when a user tries to edit a review.

**Technical**- The button label updates only during the widget initialization, as it is handled in the willStart function.
https://tinyurl.com/2derk498

**After this PR:**
The button label in the popup correctly updates to 'Update Review' when a user edits a review.

**Task**-4677251

Forward-Port-Of: odoo/odoo#211417

When changing the website view of the events from grid to list, we are losing the "Sold out, Unpublished, etc" information that was displayed on the card. This is due to loading the event calendar date widget before the rest of the elements which is provoking them to not properly load. opw-4597647 ## Before:  ## After: ![image](https://github.com/user-attachments/assets/c02aca35-c2c6-4c43-90

When changing the website view of the events from grid to list, we are losing the "Sold out, Unpublished, etc" information that was displayed on the card. This is due to loading the event calendar date widget before the rest of the elements which is provoking them to not properly load.

opw-4597647

## Before:

![image](https://github.com/user-attachments/assets/c335f7fd-fd8f-40ad-8202-6e39a7277b4b)


## After:

![image](https://github.com/user-attachments/assets/c02aca35-c2c6-4c43-902a-7748708c104d)

Forward-Port-Of: odoo/odoo#199830

Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since readi

Description
-----------
Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`.

This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since reading `employee_ids` returns an empty list -> all employees.

This commit adds a context key to take archived records when regenerating work entries.

Reference
---------
opw-4813590


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

Forward-Port-Of: odoo/odoo#212117
Forward-Port-Of: odoo/odoo#211748

Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice t

Description of the issue/feature this PR addresses:
- This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. 
- This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So `l10n_it_document_type` field is set as non-copy. A `debit_note` key is added in the mapping of invoice features to document features if the invoice is a debit note.

- The tag in the XML template with the invoice linked to the debit note was changed based on requirements. Also, reference invoice name and date were added in XML if invoice is debit note.

tasks-4744444

Current behavior before PR:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note.
- When creating a debit note from a customer invoice, the new invoice has TD01 document type

Desired behavior after PR is merged:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Bill.
- When creating a debit note from a customer invoice, the new invoice has TD05 document type

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

Forward-Port-Of: odoo/odoo#209072

**[FIX] test_http: make test_webjson_list_args reliable** The domain in the query-string is quoted by werkzeug, but there are multiple possible equivalent quoting strategy and the test sometimes fails because it is quoted differently. The test is not about testing the different quoting strategy, use a proper url parser to make the test more resilient. **[FIX] test_http: more reliable test_models3** The quote in the returned text sometimes get escaped, sometimes not, sometimes with

**[FIX] test_http: make test_webjson_list_args reliable**

The domain in the query-string is quoted by werkzeug, but there are
multiple possible equivalent quoting strategy and the test sometimes
fails because it is quoted differently. The test is not about testing
the different quoting strategy, use a proper url parser to make the test
more resilient.

**[FIX] test_http: more reliable test_models3**

The quote in the returned text sometimes get escaped, sometimes not,
sometimes with a different QP code. Remove the quote, since the test is
not about them, to make the test more reliable.

Forward-Port-Of: odoo/odoo#212333

commit 163b337fce6d3d67412f0e34e8120fbd5d02f463 didn't take into consideration that is_view_enabled can return None and the intended default behavior should be to show it by default --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211847

commit 163b337fce6d3d67412f0e34e8120fbd5d02f463 didn't take into consideration that is_view_enabled can return None and the intended default behavior should be to show it by default



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

Forward-Port-Of: odoo/odoo#211847

Steps to reproduce: - Go to any Report (Ex: Sale Analysis) - Switch to the pivot view - Add on y-column any **int** field - Download as csv Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file. opw-4762807 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-

Steps to reproduce:
- Go to any Report (Ex: Sale Analysis)
- Switch to the pivot view
- Add on y-column any **int** field
- Download as csv

Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file.

opw-4762807

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

The test for the self-order feature was failing due to a validation error in the web_tour registry. The issue comes from the use of an unrecognized key 'test' in the tour configuration of 'self_order_pricelist'. This change removes the invalid 'test' key from the tour definition. Forward-Port-Of: odoo/odoo#212513

The test for the self-order feature was failing due to a validation error in the web_tour registry. The issue comes from the use of an unrecognized key 'test' in the tour configuration of 'self_order_pricelist'.

This change removes the invalid 'test' key from the tour definition.

Forward-Port-Of: odoo/odoo#212513

runbot-error-108129 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#212509

runbot-error-108129

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

### Issue: `helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face. ### Solution: Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color. opw-4703331 Forward-Port-Of: odoo/enterprise#86573

### Issue:
`helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face.

### Solution:
Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color.

opw-4703331

Forward-Port-Of: odoo/enterprise#86573

Add the computed current year profit/loss to the balance sheet to have the full picture as expected Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#83875

Add the computed current year profit/loss to the balance sheet to have the full picture as expected

Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system.

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#83875

The "Fetch from CodaBox" link displayed on the accounting dashboard had no gap between it and the button at the left of it, and wasn't aligned horizontaly with the other buttons next to it making it look out of place. It is now displayed as a link button, which solve both problems. task-4671468 Purpose The fetch from CodaBox is too sticky to the upload button  After this commit : ![2025

The "Fetch from CodaBox" link displayed on the accounting dashboard
had no gap between it and the button at the left of it, and wasn't
aligned horizontaly with the other buttons next to it making it look
out of place.

It is now displayed as a link button, which solve both problems.

task-4671468

Purpose
The fetch from CodaBox is too sticky to the upload button

![image](https://github.com/user-attachments/assets/6edd426e-0438-4969-949f-5c18212384d4)

After this commit :

![2025-05-07_11-05](https://github.com/user-attachments/assets/749ae892-e751-4138-a836-c231ff5cd74d)

Forward-Port-Of: odoo/enterprise#84858

Following this commit : ==== - An online/offline toggle option is provided for the food delivery dropdown. - If the user has configured more than one provider and wishes to close/off one of the aggregator, then without going on the backend from the UI itself, the user can offline that particular provider and vice versa. task-4582032 Forward-Port-Of: odoo/enterprise#80333

Following this commit :
====
- An online/offline toggle option is provided for the food delivery dropdown.
- If the user has configured more than one provider and wishes to close/off one of the aggregator, then without going on the backend from the UI itself, the user can offline that particular provider and vice versa.

task-4582032

Forward-Port-Of: odoo/enterprise#80333

Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice. **Steps to Reproduce:** - Install the `l10n_co_dian` module. - Change the default company to **CO Company**. - Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset. - Send the invoice. **Error:** `AttributeError - 'bool' object has no attribute 'rjust'` Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_

Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice.

**Steps to Reproduce:**
- Install the `l10n_co_dian` module.
- Change the default company to **CO Company**.
- Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset.
- Send the invoice.

**Error:**
`AttributeError - 'bool' object has no attribute 'rjust'`

Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_co_edi_type` without ensuring it is a string. When the field is `False`, it results in an Attribute error. - [1]

This commit ensures the right access to `rjust()` only when `l10n_co_edi_type` is a valid string, preventing the error.

[1] - https://github.com/odoo/enterprise/blob/8d7a13822e9fd480a6e279ff93e29834a6668536/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L974-L975

Sentry - 6622171121

Forward-Port-Of: odoo/enterprise#86211

Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246 Forward-Port-Of: odoo/enterprise#85857

Update on the filterExchangeRate function.

The text input allowed users to enter non-numeric characters, which led to
float conversion errors during processing.

Now we parse the string into a float, catch errors and notify the user that the number was not valid.
It also enables the user to use the thousands and decimal separators based on the language of the user.

opw-4788246

Forward-Port-Of: odoo/enterprise#85857