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

*: website_appointment__account_payment, website_enterprise

In order to easily display existing appointments on the website, add an 'Appointments'
dynamic snippet. It will display punctual and recurring appointments, published and
linked to the current website (or all).

Also, a few options are added:
- One can filter on Users / Resources
- If one of those is used, the user can select existing users / resources to
filter the displayed appointments
- Also, one can specify a list of comma separated names that will be used to
search appointments based on 'name'.

Some placeholder data is added. The snippet template is the same one as appointment
cards on the front-end. Therefore, the card template has been split into sub
templates, being called in the snippet one. The split is done in a separate commit.
The main difference is the display of the sample ribbon.

The previous 'Appointment' snippet, which adds a button that can redirect to
appointments (with some options) is renamed (in strings, not in the files, to avoid
versioning the snippet) to 'Appointment Button' to be more explicit.

In a separate commit, align domains used to fetch and choose appointment types for
the s_online_appointment snippet. (including both website and datetime domains)

Task-3889948

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

This PR introduces a `l10n` test over the Balance Sheet reports.

Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested.
The test generates a journal entry with a line in every account that is not `off_balance`.
It then checks whether the Balance Sheet is balanced.
The test does this both for debits and for credits.

The test will give a warning for any installed Balance Sheet report which is not specified in the LOC_DATA global. The aim is to change this to an error once all existing Balance Sheets are tested, to make this test mandatory for any new localizations.

For each localization with a Balance Sheet, the test needs to know the XMLIDs of:
- the CoA
- the Balance Sheet report
- the Total Assets line of the Balance Sheet
- the Total Liabilities line of the Balance Sheet
- the Total Equity line of the Balance Sheet (if applicable)

Setting the global `IDENTIFY_INCORRECT_ACCOUNTS` to `True` switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot. 

**Performance impact**
- For each Balance Sheet, the test does the following:
     - load the chart template
     - create an account.move with 4 AMLs for each account (one debit and credit in the account; and one debit and credit in the counterpart account)
     - generate the report once.
- The Binary Search (which can be toggled when testing locally) is quite efficient: 
    - If there is just one incorrect account, then the report needs to be generated `log2(<number of accounts>)` times.
    - If there are `X` incorrect accounts, then in the worst-case the report may need to be generated `X * log2(<number of accounts>)` times.

On the Belgian CoA, with no incorrect accounts, the test takes 14s on my PC. With 4 incorrect accounts, the test takes 33s.

Task: 3060790

Forward-Port-Of: odoo/enterprise#66007
Forward-Port-Of: odoo/enterprise#36838

Before this commit, selection item options were not updated properly.

1. When adding some options, validating and then removing the options
and go to sign, the removed options would still be there.
This happened because when passing an empty array to the backend
it would be recognized as an empty set of commands,
it's like we are telling odoo to do nothing.

To fix this we use the command [6, false, [new_ids]].

2. `state.option_ids` were updated using `changes.option_ids` which is very fragile,
for example in 16.0 we the changes are given in the form of `[6, false, [id1, id2, ..]]`
but in 17.0 we have a list of commands for adding and removing for example `[[4, id1], [3, id2]]`
To count on some fixed form of updates would introudce bugs if this form changes in future.

To fix this we use `record.data.option_ids.currentIds` which is basically the live set of Ids.

3. when updating both options and responsible at the same time before validating,
responsible won't update. This happened becase of the return statement when the options change.

To fix this wer remove the return keyword and allow them both to be updated.

Task: 3972994

Forward-Port-Of: odoo/enterprise#64333

### Steps to reproduce the issue:

1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy
2. Go to _Field Service > Configuration > Projects_ and choose a Project
3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created
4. Create a Task for the Project
5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour
6. Click on "Mark as done", then "Sales Order"
7. The Delivered Quantities have a correct value but the Ordered Quantities do not

### Explanation:

An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`.
https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392

### Suggested Fix:

To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it.

opw-3858530

Forward-Port-Of: odoo/enterprise#65855
Forward-Port-Of: odoo/enterprise#63337

### Steps to reproduce:

- Install mrp_quality and uninstall mrp_workrder
- Create products A, B, and C 
  - Product A: Storable, Manufacturing: 
    - BOM: - 1 x product B 
  - Product B: Storable,  tracked by Lot, Manufacturing route with: 
    - BOM: - 1 x Product C
    - Quality check: Op manufacturing and Control Per Quantity 
  - Product C: Storable, On hand quantity of 10
- Create MO for product B and complete it with a Lot id
- Create MO for product A > confirm

#### > Traceback error

### Cause of the issue:

The `move_id` field of the `quality.check` model is used in the `_update_lot_from_lot_line` method of that same model. However, the method is defined in the `quality_mrp` module while the `move_id` field is defined in the `mrp_workorder` module.

Since `quality_mrp` depends on `mrp` and since `mrp_workorder` is auto installed when `mrp` is installed, this should not be an issue. However, since `mrp_workorder` is not a strict dependency of the `quality_mrp` module, the later in not uninstalled when `mrp_workorder` is. As such, it is possible to not have a `move_id` field on the `quality.check` model while the filed is used in the call of the `_update_lot_from_lot_line` mdethod defined in `quality_mrp`.

### For the posterity:

The method was introduced by commit 8ab6c56 in saas-16.4 for a fix and was later an later updated by commit 801ff42 for an other fix.

opw-3994004
---

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