Network scan/analysis tools can be useful when debugging configurations., so we added `arp-scan` and `mtr`. Forward-Port-Of: odoo/odoo#216164 Forward-Port-Of: odoo/odoo#216058

Network scan/analysis tools can be useful when debugging configurations., so we added `arp-scan` and `mtr`.

Forward-Port-Of: odoo/odoo#216164
Forward-Port-Of: odoo/odoo#216058

Before this commit: When adding any statement line with a date in the future, the amount is reflected in the journal's final balance. While it's not considered when calculating the graph points of the dashboard. Which results in a discrepancy between balances and graph points of all past points. With this commit: Future points are considered in graph points aggregation and visualization. Steps: 1- Create 2 bank transaction in a bank journal one with date in the past, the other in futu

Before this commit:
When adding any statement line with a date in the future, the amount is reflected in the journal's final balance.
While it's not considered when calculating the graph points of the dashboard.
Which results in a discrepancy between balances and graph points of all past points.

With this commit:
Future points are considered in graph points aggregation and visualization.

Steps:
1- Create 2 bank transaction in a bank journal one with date in the past, the other in future.
2- Check dashboard graph points of past transaction, will notice a difference between the graph point and real balance. (difference amount is exactly equal the future transaction amount)

opw-4823770

Forward-Port-Of: odoo/odoo#216102
Forward-Port-Of: odoo/odoo#214641

Before this commit: =================== - Cash in/out time was displayed incorrectly, not reflecting the local timezone. - Today's cash in/out date was shown as the actual date instead of using the `Today` label. - The cash in/out label was not properly aligned for responsive UI. Issue: ====== - The datetime was stored in UTC but interpreted using the system timezone, causing a mismatch. - The value was already a DateTime object but was unnecessarily re-parsed, leading to incorrect res

Before this commit:
===================
- Cash in/out time was displayed incorrectly, not reflecting the local timezone.
- Today's cash in/out date was shown as the actual date instead of using the `Today` label.
- The cash in/out label was not properly aligned for responsive UI.

Issue:
======
- The datetime was stored in UTC but interpreted using the system timezone, causing a mismatch.
- The value was already a DateTime object but was unnecessarily re-parsed, leading to incorrect results.

After this commit:
==================
- Cash in/out time now displays correctly according to the local timezone.
- Today's date is properly labeled as `Today` instead of displaying the date directly.
- Cash in/out labels are properly aligned and displayed across different screen sizes for responsive UI.

Task-4862777

Forward-Port-Of: odoo/odoo#214198

[FIX] l10n_in_ewaybill: Prevent duplicate e-way bills during demo data load Steps to Reproduce: 1. Run the Odoo app from the terminal without installing demo data. 2. Install the l10n_in_ewaybill module. 3. Load demo data from the App Settings. 4. Select the IN Company. 5. Open any invoice. Issue: - An error occurs when opening the invoice page. Reason: - The method that generates demo data was being called twice during demo data loading. - As a

[FIX] l10n_in_ewaybill:  Prevent duplicate e-way bills during demo data load

Steps to Reproduce:
    1. Run the Odoo app from the terminal without installing demo data.
    2. Install the l10n_in_ewaybill module.
    3. Load demo data from the App Settings.
    4. Select the IN Company.
    5. Open any invoice.

Issue:
    - An error occurs when opening the invoice page.

Reason:
    - The method that generates demo data was being called twice during demo data loading.
    - As a result, two e-way bills were created per invoice instead of one, which led to errors.
    - Additionally, the condition in the account.move model was assuming only one e-way bill per invoice, causing incorrect logic.

Fix:
    - Added a check before creating the e-way bill to verify whether it has already been created or not
    - Also fixed the logic in the account.move model to properly handle the e-way bill state check.

task: 4777642

Forward-Port-Of: odoo/odoo#216165
Forward-Port-Of: odoo/odoo#208825

After [1], each button is separated and therefore has its own border radius and background color. On the backend side, using the ´.btn-light´ class works well since it matches the background of our views. However, on the frontend, the background color is dynamic and does not match the page background, leading to a visually awkward result. One possible solution is to reintroduce the ´.btn-group´ class, but only wrap the "Previous" and "Next" buttons, which makes sense. However, we pre

After [1], each button is separated and therefore has its own
border radius and background color. On the backend side, using
the ´.btn-light´ class works well since it matches the background
of our views. However, on the frontend, the background color is
dynamic and does not match the page background, leading to a
visually awkward result.

One possible solution is to reintroduce the ´.btn-group´ class,
but only wrap the "Previous" and "Next" buttons, which makes sense.

However, we preferred to simply remove ´.btn-light´, which eliminates
background and border issues. We only want a hover effect, similar
to the one already implemented for the modal "expand" button.

The result is consistent across Community, Enterprise, Backend,
Frontend, and Dark mode.

Additionally, the font size has been removed to ensure consistent
button height, and ´text-transform´ no longer seems necessary.

[1]: https://github.com/odoo/odoo/commit/e2b78fca435f268515f9593c2af821616aff7ebb

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

Steps to reproduce: - Open website builder and click on header - Set "Header Position" to "Over The Content" - Set the "Background" color to one of the suggestion (not from the arbitrary picker) - Set the "Text Color" to one of the suggestion from the "Custom tab" - Save - Bug: The colors of the header are reset to default This issue was introduced during the initial refactor of website builder Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 Forward-Port-Of:

Steps to reproduce:
- Open website builder and click on header
- Set "Header Position" to "Over The Content"
- Set the "Background" color to one of the suggestion (not from the arbitrary picker)
- Set the "Text Color" to one of the suggestion from the "Custom tab"
- Save
- Bug: The colors of the header are reset to default

This issue was introduced during the initial refactor of website builder

Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641

Forward-Port-Of: odoo/odoo#215423

Before this commit, the "jump present" button when scrolling to older messages was displayed when going quite far in older messages. This happens because condition was: greater distance of either 3 times the view port client height and 10 times the height of most recent messages. When most recent messages are very big, this can be long until to see the jump to present. Also when there are lots of messages, 3 times the scroll client height can be a bit too much. In the past the "jump to

Before this commit, the "jump present" button when scrolling to older messages was displayed when going quite far in older messages.

This happens because condition was: greater distance of either 3 times the view port client height and 10 times the height of most recent messages.

When most recent messages are very big, this can be long until to see the jump to present.
Also when there are lots of messages, 3 times the scroll client height can be a bit too much.

In the past the "jump to present" UI was a banner so we were tempted to show when user was likely to want to jump to present. This is a small button now so we can be much more eager to its showing.

This commit removes the condition to recent message height and just uses the height of scroll client height for the showing of jump to present.

Before / After
![before](https://github.com/user-attachments/assets/2ced4066-f7d7-4cd3-aec8-3f3dcaa16867) ![after](https://github.com/user-attachments/assets/e12ca32c-9fe0-4714-9151-a04c4379c0a3)

Forward-Port-Of: odoo/odoo#213833

Mock server was missing `livechat_member_type`, which can lead to issues when JS features are `livechat_member_type` aware. Forward-Port-Of: odoo/odoo#216412

Mock server was missing `livechat_member_type`, which can lead to issues when JS features are `livechat_member_type` aware.

Forward-Port-Of: odoo/odoo#216412

The purpose of this commit is to allow the creation of chats without any user (when on the command palette ctrl+k "create chat"). This gives the possibility to quickly create a conversation and later on invite people either with the link or directly to add users. It was already to achieve the same result with "start a meeting" but it had the side-effect of starting a call. This commit is only creating the channel without starting the call. task-4860930 --- I confirm I have signed th

The purpose of this commit is to allow the creation of chats without any user (when on the command palette ctrl+k "create chat").

This gives the possibility to quickly create a conversation and later on invite people either with the link or directly to add users.

It was already to achieve the same result with "start a meeting" but it had the side-effect of starting a call. This commit is only creating the channel without starting the call.

task-4860930

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

Forward-Port-Of: odoo/odoo#215825

When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#216186 Forward-Port-Of: odoo/odo

When building `base_tax_line_mapping`, the JOIN on
`affecting_base_tax_ids` was effectively scanning the CTE as many times
as there were tax lines in the domain. This lead to computing a number
of rows equivalent to the number of base lines times the number of tax
lines; so O(n²).
Using a LATERAL JOIN helps in avoiding that behavior and only getting
the lines needed in each loop.Description of the issue/feature this PR addresses:

Forward-Port-Of: odoo/odoo#216186
Forward-Port-Of: odoo/odoo#215411

Before this commit, new livechat status feature has some usability issues: - icons of status were poor: `.fa-circle` is not unique enough and looks like IM status - icons were inconsistent: info panel uses different icons - info panel buttons do not look good: text not aligned, border too harsh with strange spacing, etc. - feature is cumbersome to use: can only be changed in panel, so lots of clicks when not in discuss app and conversation not selected. - feature was not displayed in some

Before this commit, new livechat status feature has some usability issues:

- icons of status were poor: `.fa-circle` is not unique enough and looks like IM status
- icons were inconsistent: info panel uses different icons
- info panel buttons do not look good: text not aligned, border too harsh with strange spacing, etc.
- feature is cumbersome to use: can only be changed in panel, so lots of clicks when not in discuss app and conversation not selected.
- feature was not displayed in some contexts like chat bubbles
- livechat status not easy to see in discuss sidebar when next to unread counter

This commit makes the following improvements to livechat status feature:
- new icons for livechat status
- better button style in panel
- livechat status is visible in all context with proper style
- can quickly change livechat status from thread actions, including discuss sidebar more actions
- livechat icon is floating in top-left of avatar for better visibility of status (exception: chat window is before avatar for space constraints)

Before 
<img width="901" alt="before" src="https://github.com/user-attachments/assets/4b5919c8-32bc-4db6-aa92-82d6b0dcf54f" />

After
<img width="896" alt="Screenshot 2025-06-25 at 16 30 52" src="https://github.com/user-attachments/assets/2bf20825-f3a7-4ea4-a1f8-2e63b882dfde" />
<img width="67" alt="Screenshot 2025-06-24 at 17 45 55" src="https://github.com/user-attachments/assets/0d1fd50f-30d7-4b5a-a473-255bccf1e4c0" />


----

With the addition of quick action to change livechat status, this commit adds these new features:

1. thread action icons can be defined in dedicate templates, for more creativity in making icon than `.fa` and `.oi` classnames.
2. useHover() now works with nested overlay: this works by warping dropdown content in a `<UseHoverOverlay hover="hover">` component.

---

Technical details of useHover nested overlay improvement:
To make it work, the content of 1st dropdown should be wrapped in a `<UseHoverOverlay>` component and provide the `hover` object of `useHover()`. The overlay content is put in slot of this component.

This `<UseHoverOverlay>` component works by helping `hover` object to make use of `contains()` function of overlay, which tells precisely if a target is inside the overlay including nested dropdowns.

Note that sub-dropdowns menu can optionally have `<UseHoverOverlay>`:
- without it, they are persistently displayed until click away or mouseleave from parented dropdown (if has `useHoverOverlay`)
- with it: mouse-leave on it outside of whole overlay closes all the related overlays.

This commit also do some related code-cleaning with useHover:
- "*" suffix syntax is removed. This was used as a way to get the direct parent element of ref. Floating menu were disappearing immediately `onAway`, but there's a global 100ms now so we don't need 2 hover triggers to be exactly next to each other

Forward-Port-Of: odoo/odoo#215447

enterprise: https://github.com/odoo/enterprise/pull/88606 This commit adds behavior to the busy IM status. This status replaces the "mute all" behavior, with the exception of hiding counters and the addition of rejecting incoming calls and muting sound alerts. task-4889586 Forward-Port-Of: odoo/odoo#215866

enterprise: https://github.com/odoo/enterprise/pull/88606

This commit adds behavior to the busy IM status.
This status replaces the "mute all" behavior, with the exception of hiding counters and the addition
of rejecting incoming calls and muting sound alerts.

task-4889586

Forward-Port-Of: odoo/odoo#215866

In some cases the value passed might be not string (e.g. a number), so we don't need to check if it starts with ('var(--)'). Also, since the data-* attributes are always strings we need to convert the value to a string when comparing them. To replicate the error, open website and start editing, drop a "Discussion Group" snippet, click on it, go to the Discussion Group option and change its value to something else => We have an error. This commit follows [the html_builder refactoring].

In some cases the value passed might be not string (e.g. a number), 
so we don't need to check if it starts with ('var(--)'). Also, since the data-* attributes
are always strings we need to convert the value to a string when comparing them.
To replicate the error, open website and start editing, drop a "Discussion Group" snippet, 
click on  it, go to the Discussion Group option and change its value to something else
=> We have an error. 
This commit follows [the html_builder refactoring].

[the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb

Related to task-4367641

Forward-Port-Of: odoo/odoo#214200

Before this commit, test "test_star_message" was failing frequently on runbot at step to check message was starred have click on "Mark as Todo". This happens because when click on mark as todo, the message is asynchronously starred. However, there's no visual indication other than the message action have yellow filled star icon. This requires hovering the message to see it, but we don't know when we should exactly hover the message to see it. This commit fixes the issue by adding a `data-s

Before this commit, test "test_star_message" was failing frequently on runbot at step to check message was starred have click on "Mark as Todo".

This happens because when click on mark as todo, the message is asynchronously starred. However, there's no visual indication other than the message action have yellow filled star icon. This requires hovering the message to see it, but we don't know when we should exactly hover the message to see it.

This commit fixes the issue by adding a `data-starred` on the `o-mail-Message` root node of message template that tells whether the message is starred or not. This removes necessity to hover to check whether message is starred.

Fixes runbot-227568

Forward-Port-Of: odoo/odoo#216466
Forward-Port-Of: odoo/odoo#216106

Steps to reproduce: - Open the Logistics / Manufacturing dashboard - Click on OdooBot in the Top Responsible Section - Boom Task: 4894828 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#215849

Steps to reproduce:
- Open the Logistics / Manufacturing dashboard
- Click on OdooBot in the Top Responsible Section
- Boom

Task: 4894828

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

Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88563 Forward-Port-Of: o

Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation.

Forward-Port-Of: odoo/enterprise#88563
Forward-Port-Of: odoo/enterprise#88341

community: https://github.com/odoo/odoo/pull/215866 This commit adds behavior to the busy IM status. This status replaces the "mute all" behavior, with the exception of hiding counters and the addition of rejecting incoming calls and muting sound alerts. task-4889586 Forward-Port-Of: odoo/enterprise#88606

community: https://github.com/odoo/odoo/pull/215866

This commit adds behavior to the busy IM status.
This status replaces the "mute all" behavior, with the exception of hiding counters and the addition
of rejecting incoming calls and muting sound alerts.

task-4889586

Forward-Port-Of: odoo/enterprise#88606

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#86823 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#86823
Forward-Port-Of: odoo/enterprise#83875

Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88704 Forward-Port-Of: odoo/enterprise#88261

Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²).

Forward-Port-Of: odoo/enterprise#88704
Forward-Port-Of: odoo/enterprise#88261

opw-4816130 Forward-Port-Of: odoo/enterprise#88744

opw-4816130

Forward-Port-Of: odoo/enterprise#88744

When we are trying to auto review returns, we are not checking if the return is a new return and it was possible for checks in the submitted state to be set back to the reviewed state. task-4900867 Forward-Port-Of: odoo/enterprise#88638

When we are trying to auto review returns, we are not checking if the return is a new return and it was possible for checks in the submitted state to be set back to the reviewed state.

task-4900867

Forward-Port-Of: odoo/enterprise#88638

When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88699 Forward-Port-Of: odoo/enterprise#88493

When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed.

opw-4812421

Forward-Port-Of: odoo/enterprise#88699
Forward-Port-Of: odoo/enterprise#88493