Live chat displays a welcome message when the visitor opens the chat. However, when an operator sends a chat request, the welcome message is not necessary as the first operator message will act as a welcome message. Before [1], chat requests data were inserted directly into the JS and the information about who opend the chat was given. However, the data is now fetched from the server and this information is missing. This PR adds this information so that the client can decide whether to

Live chat displays a welcome message when the visitor opens the chat. However, when an operator sends a chat request, the welcome message is not necessary as the first operator message will act as a welcome message.

Before [1], chat requests data were inserted directly into the JS and the information about who opend the chat was given.

However, the data is now fetched from the server and this information is missing.

This PR adds this information so that the client can decide whether to display this message.

Steps to reproduce this issue:
- Go on the website as a visitor
- Send a chat request from admin, send a first message
- Navigate to another page with the visitor
- The welcome message appears in addition to the operator message.

[1]: https://github.com/odoo/odoo/pull/142155

Before:
![image](https://github.com/odoo/odoo/assets/48757558/aaf1861d-f836-465f-b464-4cdecb43c929)

After:
![image](https://github.com/odoo/odoo/assets/48757558/1105b104-6ad7-4c72-9364-16fd6ee571c2)

Forward-Port-Of: odoo/odoo#169476

`to_recheck_leaves` stores every leave that is not yet taken into account by the "allocation_leaves_consumed" dictionary. now for some leave type, it's allocation contain False value as key of this `allocation_leaves_consumed` dictionary. because when leave_type with requires_allocation Is not yes then we pass leave type data with False as allocation. see: https://github.com/odoo/odoo/blob/7363d568df6e82119eed1cec55b3ae67a3816a1a/addons/hr_holidays/models/hr_employee.py#L565 and this wi

`to_recheck_leaves` stores every leave that is not yet taken into account by the "allocation_leaves_consumed" dictionary. now for some leave type, it's allocation contain
False value as key  of this `allocation_leaves_consumed` dictionary.
because when leave_type with requires_allocation
Is not yes then we pass leave type data with False as allocation.
see:
https://github.com/odoo/odoo/blob/7363d568df6e82119eed1cec55b3ae67a3816a1a/addons/hr_holidays/models/hr_employee.py#L565

and this will create issue when we try to calculate `latest_accrual_bonus` value by iterating  consumed_content which call `_get_future_leaves_on` function but as we got allocation as False will get error :

```
 File "/home/odoo/src/odoo/17.0/addons/hr_holidays/models/hr_employee.py", line 105, in _compute_allocation_remaining_display
    leaves_taken = self._get_consumed_leaves(allocations.holiday_status_id)[0]
   File "/home/odoo/src/odoo/17.0/addons/hr_holidays/models/hr_employee.py", line 582, in _get_consumed_leaves
    latest_accrual_bonus += allocation._get_future_leaves_on(date_to_simulate)
 AttributeError: 'bool' object has no attribute '_get_future_leaves_on'
```

Generated during upgrade.

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

Display IoTBox connected devices on its display. Task: 3960101 Forward-Port-Of: odoo/odoo#168833

Display IoTBox connected devices on its display.

Task: 3960101

Forward-Port-Of: odoo/odoo#168833

In this commit, we changed the way the addresses were displayed in accounting. https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e We now want the same behavior with the sale orders. task-3951205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166877

In this commit, we changed the way the addresses were displayed in accounting.
https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e
We now want the same behavior with the sale orders.

task-3951205




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

Forward-Port-Of: odoo/odoo#166877

Issue: At some point we added the daterange widget to select the dates for the resource leaves without taking into account certain cases, the most relevant is that we have a compute_date_to which depends on the date_from, the duty of this compute is that whenever we select a date_from, we will get the date_to to allocate exactly 1 day, which is the most common use, the problem is that with this widget we will always modify both date_from and date_to at the same time, making the compute to be

Issue:

At some point we added the daterange widget to select the dates for the resource leaves without taking into account certain cases, the most relevant is that we have a compute_date_to which depends on the date_from, the duty of this compute is that whenever we select a date_from, we will get the date_to to allocate exactly 1 day, which is the most common use, the problem is that with this widget we will always modify both date_from and date_to at the same time, making the compute to be called everytime which will not allow us to select a further date for date_to.

Steps to reproduce:

1. Install Appointments.
2. Go to Configuration > Resource Leaves > New
3. Try to allocate more than 1 day for the Resource Time Off

Solution:

We should, at least for the moment, keep it as it was before, where we can select both dates separetely, this way whenever we select our date_from we will get the date_to updated automatically to make things easier for the most common case, but we will still be able to change the date_to without triggering the compute.

opw-3861325

Forward-Port-Of: odoo/odoo#161715

Current behaviour: --- When scheduled_date is not set, we get a traceback Steps to reproduce: --- 1. Create Product FNS storable 2. Create Product CMP storable 3. Create quant for 10 units of CMP 4. Set CMP tracking to 'Lot' and 'Use expiration date' to True 5. Create MO for 1 unit of FNS using 1 unit of CMP 6. Try to Confirm: Traceback Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/f1d4a727a84672d974151f681e43768abd3ac7cc opw-3981689 --- I confirm

Current behaviour:
---
When scheduled_date is not set, we get a traceback

Steps to reproduce:
---
1. Create Product FNS storable
2. Create Product CMP storable
3. Create quant for 10 units of CMP
4. Set CMP tracking to 'Lot' and 'Use expiration date' to True
5. Create MO for 1 unit of FNS using 1 unit of CMP
6. Try to Confirm: Traceback

Cause of the issue:
---
Caused by: https://github.com/odoo/odoo/commit/f1d4a727a84672d974151f681e43768abd3ac7cc

opw-3981689

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

Forward-Port-Of: odoo/odoo#169052

Back Porting commit - https://github.com/odoo/odoo/pull/147812/commits/5bd0d647094d00f93d73a4498e571e84a6317446 and https://github.com/odoo/odoo/pull/147812/commits/5c755e4148399d80717d0047c55a7833f7bdfdde Commit merged in PR - https://github.com/odoo/odoo/pull/147812 (in saas-17.3) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169502 Forward-Port-Of: odoo/odoo#169224

Back Porting commit - https://github.com/odoo/odoo/pull/147812/commits/5bd0d647094d00f93d73a4498e571e84a6317446 and https://github.com/odoo/odoo/pull/147812/commits/5c755e4148399d80717d0047c55a7833f7bdfdde

Commit merged in PR - https://github.com/odoo/odoo/pull/147812 (in saas-17.3)



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

Forward-Port-Of: odoo/odoo#169502
Forward-Port-Of: odoo/odoo#169224

Steps to reproduce: 1. As a frontend user, add a product to the cart 2. As a backend user, add a note line to the created order 3. As a frontend user, open the cart Before this commit: The note line in the order is deleted After this commit: The note line in the order is still there The note line deletion was introduced long ago with ee0199cac4f58bc8aefd0ea1410d16fb6b9f4e31, as a side-effect of deleting lines with inactive products. This commit also makes sure that notes/section

Steps to reproduce:
1. As a frontend user, add a product to the cart
2. As a backend user, add a note line to the created order
3. As a frontend user, open the cart

Before this commit:
The note line in the order is deleted

After this commit:
The note line in the order is still there

The note line deletion was introduced long ago with ee0199cac4f58bc8aefd0ea1410d16fb6b9f4e31, as a side-effect of deleting lines with inactive products.

This commit also makes sure that notes/section lines are not shown in the cart, as the current template and code are not designed to handle lines without products (it raises while trying to fetch the combination info of the soline product).

Forward-Port-Of: odoo/odoo#169275
Forward-Port-Of: odoo/odoo#168521

The "Reload Chart Template" button currently doesn't work with the argentinian localization. It is due to some python constrains that don't allow to modify some fields if there are accounting entries. The issue is that the constrains will be raised, when any writing on those fields is done, even if the new value is the same as the old one. When reloading the chart template it is re-writing the values, but they are not different, so no exception should be raised. The fix here is

The "Reload Chart Template" button currently doesn't work with the
argentinian localization.

It is due to some python constrains that don't allow to modify
some fields if there are accounting entries.

The issue is that the constrains will be raised, when any writing
on those fields is done, even if the new value is the same as the old
one.

When reloading the chart template it is re-writing the values, but
they are not different, so no exception should be raised.

The fix here is to move those constrains into the `def write` override,
where there's more control (as we have the new values as argument).

task-3878511

Forward-Port-Of: odoo/odoo#166537

## Issue: - The stock valuation for discounted purchase orders is incorrectly based on the original unit price instead of the price. ## Steps To Reproduce: - Create a storable product with AVCO costing method. - In its purchase tab set control policy "On ordered quantities". - Create RFQ for a product 10 qty with 10 unit price and add a 10% discount. - Create a vendor bill and confirm it. - Receive the product. - See the valuation, it will show 100 instead of 90. ## Solution: - I f

## Issue:
- The stock valuation for discounted purchase orders is incorrectly based on the original unit price instead of the price.

## Steps To Reproduce:
- Create a storable product with AVCO costing method.
- In its purchase tab set control policy "On ordered quantities".
- Create RFQ for a product 10 qty with 10 unit price and add a 10% discount.
- Create a vendor bill and confirm it.
- Receive the product.
- See the valuation, it will show 100 instead of 90.

## Solution:
- I fixed the issue by updating the `_get_price_unit` method to consider discounts when calculating the invoiced value.
  
opw-3895448
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#168619

### Steps to reproduce: 1. Create a BOM with 2 operations: op 1 and 2 2. Create and confirm an MO for 10 units using that BOM. 3. Put the quantity to 10 then start and done op 1 4. Put the quantity to 2 then start and done op 2 5. Produce and create a backorder 6. Put the quantity to 4 then start and done op 2 7. Produce and create a backorder #### > instead of 4 units remaining in op 2 we have 4 units remaining in op 1 ### Cause of the issue: The operations of a productions (`mr

### Steps to reproduce:

1. Create a BOM with 2 operations: op 1 and 2
2. Create and confirm an MO for 10 units using that BOM.
3. Put the quantity to 10 then start and done op 1
4. Put the quantity to 2 then start and done op 2
5. Produce and create a backorder
6. Put the quantity to 4 then start and done op 2
7. Produce and create a backorder
#### > instead of 4 units remaining in op 2 we have 4 units remaining in op 1

### Cause of the issue:

The operations of a productions (`mrp.workorder`'s) are ordered by `leave_id`, `date_start` and then `id`:
https://github.com/odoo/odoo/blob/26239b2d0bdbc2f06d50f7739d61c490248b65bb/addons/mrp/models/mrp_workorder.py#L14-L17 Since, in the first backorder, the workorder corresponding to op 1 is cancelled it has an empty `leave_id` and `date_start`. On the other hand, once the partial operation of op 2 has been completed its associated `date_start` is not empty anymore and the order of both operations is therefore swaped. However, when a backorder is created, the quantity of the workorders is set by relying on the order of operations (which is not the same with and without `leave_id`, `date_start`):
https://github.com/odoo/odoo/blob/d826c3782d737fc1724887692b71b27999bf846d/addons/mrp/models/mrp_production.py#L1973-L1983 So that the data is set on the wrong line.

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

Forward-Port-Of: odoo/odoo#166820

xlrd 2.0 removed xlsx support, and that's the version on Noble. So xlsx (the modern excel format) can't be imported on Noble. Aside from the error message being confusing (it says to install xlsx >= 1.0, which is already there) this would be fine, just no support for xlsx, except the only *export* formats are xlsx and csv, and xlsx is the default, and csv is kinda shit too. In fact when using the "Export All" quick action, the only thing you can get is xlsx. So losing xlsx support turns ou

xlrd 2.0 removed xlsx support, and that's the version on Noble. So xlsx (the modern excel format) can't be imported on Noble.

Aside from the error message being confusing (it says to install xlsx >= 1.0, which is already there) this would be fine, just no support for xlsx, except the only *export* formats are xlsx and csv, and xlsx is the default, and csv is kinda shit too. In fact when using the "Export All" quick action, the only thing you can get is xlsx.

So losing xlsx support turns out to be a concern. This can be resolved, kinda, by adding support for openpyxl. The API is pretty simple and similar to xlsx though not super well documented (especially when trying to do type dispatching). This here version seems to work with the (fairly limited) XLSX test case of base_import.

Forward-Port-Of: odoo/odoo#169245

Before this fix, when grouping by a date filter that only had "false" value, the global filter matching was causing a traceback trying to split a non existant month/year value. This commit fixes this behavior by checking for "false" in date filter and setting the matching filter to "undefied" OPW: 3776544 OPW: 3952358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169453

Before this fix, when grouping by a date filter that only had "false" value, the global filter matching was causing a traceback trying to split a non existant month/year value.

This commit fixes this behavior by checking for "false" in date filter and setting the matching filter to "undefied"

OPW: 3776544
OPW: 3952358





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

Forward-Port-Of: odoo/odoo#169453

Since 17.0, message unread counter is not reliable. Indeed, it is computed on the client side which is aware of all messages. This PR fixes this issue by backporting the PR that made the unread counter rely on the server state instead. enterprise: https://github.com/odoo/enterprise/pull/63265 Forward-Port-Of: odoo/odoo#168648 Forward-Port-Of: odoo/odoo#165955

Since 17.0, message unread counter is not reliable. Indeed, it is computed on the client side which is aware of all messages. This PR fixes this issue by backporting the PR that made the unread counter rely on the server state instead.

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

Forward-Port-Of: odoo/odoo#168648
Forward-Port-Of: odoo/odoo#165955

Description of the issue/feature this PR addresses: In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot. @qdp-odoo @oco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168339 Forward-Port-Of: odoo/odoo#161369

Description of the issue/feature this PR addresses:
In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot.

@qdp-odoo @oco-odoo 



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

Forward-Port-Of: odoo/odoo#168339
Forward-Port-Of: odoo/odoo#161369