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

**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

(wrote by LSE)

Before this commit:
 If an error happened when trying to synchronise a PoS order nothing is saved on the backend to inform the user regarding the error.
 Note: Odoo logs would contain the information, but it is out of reach for certain clients (on odoo online for instance).
 
 In theory, we can't lose any information as, if the sync process raise an exception, the order is still on the PoS browser cache that will  then try to be resync when another order sync happen.
 But, in practice, the support received some cases of "missing PoS  orders". Which can happen as we fully rely on the client browser cache that can be cleared or use another computer/browser/session.

After this commit:
 If an order can not be processed in the backend:
  - the PoS order data is saved in the PoS session attachments
  - a scheduled activity is created in the PoS session
 
 As an un-synced keep being tried to be sync (and will likely fail each time), we compare it with the already attached one to avoid having the content repeated multiple times.
 If the order was modified in between, a new attachment with the same name is created.
 
 Note: draft orders that will fail to validate are NOT stored
 
 The attachment and activity are automatically removed when the order of same reference is validated

![image](https://github.com/odoo/odoo/assets/60775325/c3a503f3-2528-44d3-b720-c82776f40238)

opw-3650239

Forward-Port-Of: odoo/odoo#167269
Forward-Port-Of: odoo/odoo#147130

Problem:
en_US data is loaded while the user uses another language

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Change the language (e.g. to french)
- Go to POS -> Products -> Discount & Loyalty
- Create a new Loyalty Card
- In Rewards, set a discount of 20 $ on order and save
- Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable)
- Click on "Reward", the earlier created reward is there
- Go back to the form of the loyalty card and change the value and save
- Go back to the shop
- Click on "Reward" and the name of the loyalty card is still the same as before while it should be for the new price

Cause:
When loading the data, the record environment have language set to None so by default it is loaded in en_US which didn't recompute its value after the modification of the price.

opw-3987961


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

Forward-Port-Of: odoo/odoo#171049

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

When a user tries to validate an invoice of the POS order a traceback will occur.

Steps to produce:

- Install 'l10n_sa_edi', 'point_of_sale', and 'contacts' modules.
- Switch to a 'SA Company' company.
- Open 'Point of Sale' and create and open New Session.
- Select any products (with customer taxes )> payment > Select payment method > Invoice > Select individual customer > Validate error will generated in the backend.

```AttributeError: 'bool' object has no attribute 'encode'```

This is because 'signature' is 'False' at [1] while generating an invoice for an order and a system tries to encode it.

link [1]: https://github.com/odoo/odoo/blob/149a2acea96cff14990b667ee611c3afbdc146f2/addons/l10n_sa_edi/models/account_move.py#L115

This commit solves the above issue by adding a condition if 'signature' is 'False'  then encodes a blank string.

sentry-5482247880

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

Forward-Port-Of: odoo/odoo#169407

Improve some shortcomings of the comparison system applied on history revisions.

* Better handling of diffs generated by changes in html parameters:
> Previous system was generating unnecessary HTML opening tags in those cases.

* Better handling of addition or deletion in previously empty HTML tags.
> Previous system was generating unnecessary HTML opening tags in those cases.

* Better handling of HTML tag replacement.
> Previous system was generating invalid HTML in those cases.

* Trade off the comparison generated on some complex changes to be able to display correct HTML
> When we have both an HTML parameter change on the container tag and a content
> change, we choose to display both `<added>` and `<removed>` in the same
> container.
> The current system is not smart enough to generate a better comparison and
> would require extensive refactoring to handle this better.

task-3761721


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

Forward-Port-Of: odoo/odoo#171276
Forward-Port-Of: odoo/odoo#160460

PR does 2 things:

- First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double check if any of the translations in from these es_CL files should remain.
- Cleanup the en_AU/en_GB.po files. There were some non-sense "translations" in them and most of them didn't add much value. Some en_AU files had specific legitimate "translations" were left (e.g. tax "GST", check = cheque), so they were only modified to remove any erroneous translations

task: 3593077
ENT PR: https://github.com/odoo/enterprise/pull/65875
v17 PR: https://github.com/odoo/odoo/pull/170183

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

Forward-Port-Of: odoo/odoo#171520

In [1] when the translation conditions were adapted to allow restricted
editors to translate, the general editability right was wrongly
impacted, making the user believe a page could be edited when it was not
the case.

This commit restores the editability condition and limits the
translatability to records that can be modified by the restricted
editor user.
A `_check_user_can_modify` is introduced to enable customization.

Steps to reproduce (described in terms of expected behavior):
- Install `website_sale` and `website_event`
- Add a language to the website
- Assign the following rights to a non-admin user:
  - Website: Restricted editor
  - Sale: Administrator
  - Event: No right
- Log in as that user
- Go to the contact us page:
  - Edit: nothing should be possible
  - Translate: not available
- Go to a product page:
  - Edit: blocks can be dropped in fields, texts can be changed
  - Translate: available and texts can be changed
- Go to an event page:
  - Edit: nothing should be possible
  - Translate: not available

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

Forward-Port-Of: odoo/odoo#171844
Forward-Port-Of: odoo/odoo#170102

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

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

**Current behavior:**
Lines in an invoice may display a product name incorrectly if
they mix arabic/latin characters.

**Expected behavior:**
These types of product names should respect the RTL syntax if
being sent to an Arabic lang partner.

**Steps to reproduce:**
*Ensure the rtlcss node package is installed and in PATH*

1. Create a Saudi company / switch to a demo one, switch to
     Arabic language

2. Create a product with the name:
   `دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة`

3. Create an invoice to a partner with Arabic set as their lang

4. Confirm the invoice -> print it

5. The product name on the PDF has a mal-ordered name

**Cause of the issue:**
The right-to-left rule of the Arabic language is not getting
enforced.

There is a secondary bug where certain whitespace-delimited
substrings get displayed in a broken, overlapping way. From my
no-comprehensive testing, it seems to only happen when there is
a sequence in the string where you have some substring ending in
a numeral (0-9) followed by a single-space, then another
substring that begins with an Arabic alphabet character.

**Fix:**
When printing an invoice with an arabic partner:
1. Use right-aligned text instead of left

2. Pad single-space breaks between substrings in a product name
     where the first substring ends with a numeral and the
     second begins with an alpha char.

3. Add explicit `dir="rtl"` attribute to the display node

opw-3971541

Forward-Port-Of: odoo/odoo#169267