Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used.

Steps to reproduce:
-------------------
* Install and configure an IoT box
* Go to **Point of Sale**
* Select the Shop, edit it
* Check `IoT Box`
* Configure `Customer Display`
* Now go to the settings of the Shop
* Enable `Customer Display` if not already done previously
* Upload a background image, save
* Open the Shop session
* Select the customer display

> Observation: The background image is not shown.

Why the fix:
------------
When using the customer display feature with the IoT box, the request is done with a Public User:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L171-L176

Since Public Users don't have reading access on the `pos.config` model, access rights & rules are triggered:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/odoo/addons/base/models/ir_binary.py#L52-L58

Since we failed the try block, we end up loading the placehorder image by default:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L185

We want the field `iface_customer_facing_display_background_image_1920` to be available to public user. In the case we are trying to access it with a public user, we make the request in sudo. Sudo environment stops existing once the request is made.

opw-3873765

Forward-Port-Of: odoo/odoo#169808

Currently, a traceback is occurring when the user clicks on the chat button while creating a new employee record.

To reproduce this issue:

1) Install `employee`
2) Create a new `employee` record
3) Give the value for the related user in the `HR Setting` page 
4) A chat button appears at the left side of the `employee name` 
5) Click on the chat button, and a traceback occurs

Error:- 
```
TypeError: '<' not supported between instances of 'int' and 'NoneType'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/mail/models/discuss/discuss_channel.py", line 973, in channel_get
    """, (tuple(partners_to), tuple(partners_to), sorted(list(partners_to)),))
```

When the related user value is given, the `chat` button is visible to the user before saving the record. 
But here in the `openChat` method, we used `props.record.resId`.
which is created after the employee record is created.

https://github.com/odoo/odoo/blob/a6c14effd3e38cf38966ae89675e8e54b54cf825/addons/hr/static/src/components/employee_chat/employee_chat.xml#L4-L11

It leads to the above traceback as `channel_get` calls with `partners_to` as `None` from the below line

https://github.com/odoo/odoo/blob/a6c14effd3e38cf38966ae89675e8e54b54cf825/addons/mail/static/src/core/common/thread_service.js#L555-L557

This commit will resolve this issue by making it visible to the user after the employee record is created.

Note:- An alternative solution can be at this line
https://github.com/odoo/odoo/blob/9f84ff581686f8e2198a0a88d19f7a52e27ccb53/addons/hr/static/src/thread_service_patch.js#L9
```
if (!person) {
            this.notificationService.add(
                _t("To open chat, please first save the record.."),
                { type: "info" }
            );
            return;
        }
```

sentry- 5501637214

Forward-Port-Of: odoo/odoo#171380

This error occurs when we keep the product name empty in the stock move and try to generate the Serials/Lots by clicking on ``Generate Serials/Lots``.

Steps to reproduce:
- Install the ``stock`` module
- Create a new product(eg: test) and set its tracking ``By Lots`` in Traceability
- Create a new receipt and add ``test`` as product and ``Mark as ToDo``
- Again add ``test`` as the product and on the right, click on ``bars(fa-icon)``
- Remove the product name > click on ``Generate Serials/Lots``
- Click on ``Generate``

Traceback: 
``KeyError 'product_id'``

This error occurs at [1] because ``product_id`` is not present in the default values.

This commit will fix the above error by not showing the ``Generate Serials/Lots`` and ``Import Serials/Lots`` buttons when ``product`` is empty and also will raise an error if ``product`` is not found.

[1]: https://github.com/odoo/odoo/blob/b1ba4018f91f1fd788f48180bd5fc4656ab1e35c/addons/stock/models/stock_move.py#L930

sentry-5072366645

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

Forward-Port-Of: odoo/odoo#170718

**Current behavior:**
When importing a repair order record, if a picking_type_id is not supplied by the data source, the import will fail.

**Expected behavior:**
Fields with default values shouldn't be required during record creation.

**Steps to reproduce:**
1. Create a .CSV with one column (e.g., `scheduled date`) and load it in the import record view in the Repair app

2. Map the CSV column to the repair model's date field

3. Click the test button to see the error (bad query)

**Cause of the issue:**
If a `picking_type_id` is not supplied, we try to get the default field value via `default_get()`. However, it is called incorrectly (string argument vs. container), so the string is iterated over and each letter is treated as a field name (none of which, of course, exist in the model).

Later in the create sequence, we assume there is a `picking_type_id` value obtained from the `default_get()` call but it is not there. This (eventually) causes the invalid query.

**Fix:**
Correct the call to `default_get()`.

opw-3813273

Forward-Port-Of: odoo/odoo#171589

In a grouped kanban view, drag and drop a record from a group which contains a lot of records and has the "Load more" displayed in the bottom (i.e. which contains more records than the limit). Before this commit, the drag&dropped record was displayed twice: once where it was dropped (which is fine), and once from where it was dragged (which is wrong).

This happened because we didn't correctly synchronize the reload of the column (which must be done because there're more records than the limit, and we "removed" one record from the column) and the update on the moved record (s.t. it belongs to the correct column). As a consequence, we reloaded the column before updating the record, so it was still part of the original column.

This commit fixes the issue by splitting the logic of the _removeRecords function: before, it altered the records locally (to filter out removed records) and updated the count, and, if necessary, it reloaded the list. Now, _removeRecords is only responsible to update the list locally, which must be done directly as we want the user to get a direct feedback of the move. In the flows where a reload might be necessary, we do it afterwards. In the case of a moveRecord, we can then do it after the update on the record.

opw-3891269

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

**Current behavior:**
Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality check to end up in the failure location.

**Expected behavior:**
A product created in a manufacturing order can fail a quality check and end up in the designated failure location in WH.

**Steps to reproduce:**
1. Set up a quality point on some storable product on manufacturing operations with:
      `Control per: Quantity`
      `Type: Pass - Fail`
      `Failure Location: Some internal location`

3. Create a new MO with the quality controlled product and confirm it

4. Click the Quality Checks button, fail the check (make sure to select the faiure location here)

5. After the Quality Check, click Produce All -> Observe that the full quantity of products produced by the MO still was moved to whatever the default Stock location is, not the failure location specified.

**Cause of the issue:**
The method `_move_line_to_failure_location()` expects a picking and SML to exist, however when the quality check starts from an MO, we have neither (contrasted with a check starting from a picking). So the method just skips the logic where the re-route would occur.

**Fix:**
Override the method in the mrp_quality bridge module, if the quality check has a production_id then create the SML on the spot via `MrpProduction.action_confirm()`, then go through the same logic to split the created line as necessary based on the failed quantity vs. total quantity of the MO.

opw-3865301

Forward-Port-Of: odoo/enterprise#62731

### Issue:

A quantity of `3` gets displayed as `3.00...004`.

### Steps to reproduce:

- Settings > Technical > Database Structure > Decimal Accuracy
- Change the `Digits` of `Product Unit of measure` to 5
- Create a storable product P1 with a BOM: - In the operation tab: one operation in `Assembly line 1` - In the component tab: 1 unit of P2 consumed in the operation
- Create and confirm an MO for 3 units of P1
- Go to the shopfloor module, remove the MO ready filter Two issues can be noticed:
- Click on Register Production A pop up opens. Before validating it:
The displayed producing quantity of P1 and the quantity of P2 that should be consumed by the operation is`3.00...004`. After validation, the produced quantity is rounded. However, if you click on the cross the rounding error will remain. In addition, the second rounding issue will remain even after validation of the consumed qty.

### Cause of the issue:

Our float utils introduce tiny rounding errors, especially at higher precisions. In our case, these errors are introduced during the call of the write method of the `web_save`.

### Fix:

We eliminate the rounding errors for the display in the same way as initially ptoposed by https://github.com/odoo/enterprise/pull/58880
see commit https://github.com/odoo/enterprise/commit/1c2f0068d319917bb4af163396d0861a1ff6c9e1 and adapt it to also apply to the raw_move_ids of the MO.

opw-3861892
---

Forward-Port-Of: odoo/enterprise#62510

Steps:
--------
- Install Field Service module
- Now, go to the field service's configuration
- Click on Time and Material invoicing
- Make the new Task
- Add products
- Now in internal user, give users access right level > sale: own document only
- Now login as a user who has user access right level
- After login, go to field service module
- Open that task in which sale order automatically generated, access error comes

Issue:
-------
- An user who has user access rights level trying to read other user sale order.

Cause:
---------
- In this **PR enterprise-31363** added a new field pricelist_id on model project.task.This field is
  computed in _compute_currency_id.However user have no access to read record,
  therefore raises an access error for internal user.

Fix:
-----
- A sudo is used in method _compute_currency_id to be able to open the
  task but can not see sale order stat button.

task-3610485

Forward-Port-Of: odoo/enterprise#66047
Forward-Port-Of: odoo/enterprise#52677