### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

Enterprise: https://github.com/odoo/enterprise/pull/77068

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

Forward-Port-Of: odoo/odoo#193465

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue POST 17.0:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move is equal to 0, it will be confirmed:
https://github.com/odoo/odoo/blob/9cce72f984c7bd5fae126945e68f3eb2c143761b/addons/stock/models/stock_move.py#L1885-L1889 `product_uom_qty`, extra moves will be created,
However, this second `_action_confirm` will also generate a quality check for the same reason:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15

### Fix:

The condition confirming non-draft moves without demand seemed to be only relevant in the flow protected by the
`test_add_sml_with_kit_to_confirmed_picking` where a move line is created by hand for a kit product on an already confirmed picking. Leading to an assined move for a kit that never triggered the `action_explode`. This
"action" transforming the kit move using the phantom bom before the _action_done and hence if not perfomed leading to an error when trying to update the quantity on the related quants:
https://github.com/odoo/odoo/blob/9cce72f984c7bd5fae126945e68f3eb2c143761b/addons/mrp/models/stock_quant.py#L11

### Note:

A similar action_explode is performed when validating a picking contnaining a move_line related to a move:
https://github.com/odoo/enterprise/blob/2877bf921633247ed733e1d1ee47a6da0e6f8051/stock_barcode_mrp/static/src/models/barcode_picking_model.js#L8-L21


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

Forward-Port-Of: odoo/odoo#192034

In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value.

Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions.

#### speedup

Test database with account_accountant and sale.
Trying to create batches of account.moves

| Batch size | Before PR | After PR |
|:----------:|:---------:|:--------:|
|     1      |    70ms   |    58ms  |
|     50     |    150ms  |    100ms |
|     100    |    275ms  |    188ms |
|     250    |    660ms  |    450ms |
|     1000   |    2.43s  |    1.75s |
|     3000   |    7.55s  |    5.33s |

Average speedup: 68%.




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

Forward-Port-Of: odoo/odoo#160313
Forward-Port-Of: odoo/odoo#157887

Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero.

### Steps to reproduce

* On any chatter, send a message containing a `.eml` attachment (another email file).
* Using Thunderbird, attempt to download that attachment.

The downloaded attachment will be empty (0 kB).

### Cause

The `.eml` file format, which represents an email message, has the MIME type `message/rfc822`. According to [RFC 2046 Section 5.2.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.2.1:~:text=No%20encoding%20other%20than%20%227bit%22%2C%20%228bit%22%2C%20or%20%22binary%22%20is%20permitted%20for%0A%20%20%20the%20body%20of%20a%20%22message/rfc822%22%20entity.), attachments of this MIME type must be encoded using `7bit`, `8bit`, or `binary`. However, the system currently encodes all attachments using Base64 by default, which is not compliant with the standard for `message/rfc822`.

Although some email clients tolerate Base64 encoding for `message/rfc822`, others, such as Thunderbird, Roundcube, and Zimbra, strictly follow the RFC and reject Base64-encoded `message/rfc822` attachments. As a result, these attachments appear invalid and are downloaded as empty files.

opw-4126522

Forward-Port-Of: odoo/odoo#198862
Forward-Port-Of: odoo/odoo#194988

To reproduce:
- on a record of a model that inherits mail.activity.mixin, create a new Activity of a 'meeting' type
- open calendar
- create 2 meetings on the calendar
- only the second one is attached to the resource record's chatter

Problem:
When the calendar view is opened, the mail.activity record has already been created, and creating the calendar.event record writes to its calendar_event_id field with the id of the newly created calendar.event. Creating a second calendar.event record in the same view does not create a second mail.activity record, instead it overwrites the calendar_event_id field of the original mail.activity record, overwriting the original calendar.event. This also causes the first calendar.event record to no longer have any associated mail.activity record in its activity_ids field.

Solution:
In the calender.event create() method, modify the condition of whether a new mail.activity record should get created so that it makes a new mail.activity record if the linked mail.activity record already has a calender_event_id

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

Forward-Port-Of: odoo/odoo#197761
Forward-Port-Of: odoo/odoo#196719

### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

Community: odoo/odoo#193465

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

Forward-Port-Of: odoo/enterprise#77068

### Issues:

Creating and validating a picking from the barcode app does not behave correctly with respect to quality check trigger and creation. Depending on your flow, you might end up with QC created twice or with QC not being triggered before validation.

### Cause of the issues:

The quality checks are created during the "_action_confirm" of moves: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15 
However, depending on where you click in the barcode app, the moves might end up being assigned and hence skip the "_action_confirm" of the picking (which is computed to be assigned) prior to the `_pre_action_done_hook` of the `button_validate` of the picking wich is suppose to return already created quality check:
https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_picking.py#L1145-L1147 
In which case, the quality check is not triggered (Issue 1). Furthermore, since  the `_action_confirm` of moves can also be applied to extra moves created to update the demand and to be merged to the initial move during the validation, the quality check creation might be called twice on a move once during its own `action_confirm` and once during the `_action_confirm` of its extra move (Issue2).

### Issue 1:

1. Create a storable product P with a barcode: XXX
2. Go to Quality > Quality Control > Quality Points > New
3. Create a new quality point for your product:
    - Control per: "Operation"
    - Operations: "Receipts"
4. Go to the barcode app > Operations > Receipts > New
5. Scan your product
6. Click on the pencil (key step)
7. Either edit the quantity from the digipad and confirm or go back to the picking and edit it from there.
8. Validate the receipt

#### > Even thought a quality check was created using your quality point for your receipt, it was not triggered before validation.

### Cause of the Issue:

Clicking on the pencil will trigger a call of the `save_barcode_data` which will in turn create a stock move line related to the picking during the write performed on the picking:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/controllers/stock_barcode.py#L68-L74 
After this edition of the quantity of the picking will write on the `qty_done` dummy field of that move line which will in turn trigger a call of its inverse method and modify its quantity: https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/stock_barcode/models/stock_move_line.py#L58-L61 
Changing the quantity of the ml will then update the state of the move to "assigned" because of these lines:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L487-L488 https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_move_line.py#L530-L531 https://github.com/odoo/odoo/blob/08f0c6481a190349369ead5ab9328886392ddbeb/addons/stock/models/stock_move.py#L2022-L2023 In turns, the state compute method of the picking will determine that the picking is assigned and the picking will not be confirmed during its `button_validate` prior to the `_pre_action_done_hook` of the `button_validate` as it is not in draft anymore.

### Fix:

The state of the move should stay as draft just as if we didn't created the move line through the pencil if we were to edit the qty_done via the barcode app.

### Note:

The inverse method of the "qty_done" computed field was introduced in 17.0+ by commit: 4f19668c51a90e8c12e57b6353bbe5194f83ca10 during the quantity refactoring so that the issue is not reproducible prior to that version.

### Issue 2:

Same steps 1 -> 5.
6'. click on the +1 button.
7'. Validate > this opens the quality check
8'. Pass the quality check > Validate again
9'. Go to Quality > Quality Control > Quality check

#### > Two quality checks were created isntead of one for your receipt

### Cause of the issue POST 17.0:

At some later point in the button validate of the picking, an `_action_done` is called to put the pickings and its move in done state:
https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/stock/models/stock_picking.py#L1157

However, during the `_action_done` of the moves if the quantity of the move is equal to 0, it will be confirmed:
https://github.com/odoo/odoo/blob/9cce72f984c7bd5fae126945e68f3eb2c143761b/addons/stock/models/stock_move.py#L1885-L1889 `product_uom_qty`, extra moves will be created,
However, this second `_action_confirm` will also generate a quality check for the same reason:
https://github.com/odoo/enterprise/blob/dd4a1ec4aaa7cbb95d6e40a8bb6ab1d6c88fc7b7/quality_control/models/stock_move.py#L12-L15

### Fix:

The condition confirming non-draft moves without demand seemed to be only relevant in the flow protected by the
`test_add_sml_with_kit_to_confirmed_picking` where a move line is created by hand for a kit product on an already confirmed picking. Leading to an assined move for a kit that never triggered the `action_explode`. This
"action" transforming the kit move using the phantom bom before the _action_done and hence if not perfomed leading to an error when trying to update the quantity on the related quants:
https://github.com/odoo/odoo/blob/9cce72f984c7bd5fae126945e68f3eb2c143761b/addons/mrp/models/stock_quant.py#L11

### Note:

A similar action_explode is performed when validating a picking contnaining a move_line related to a move:
https://github.com/odoo/enterprise/blob/2877bf921633247ed733e1d1ee47a6da0e6f8051/stock_barcode_mrp/static/src/models/barcode_picking_model.js#L8-L21

opw-4266053
---

Forward-Port-Of: odoo/enterprise#76301

This traceback arises when the user tries to change the orders from one stage to another.
after deleting the last stage in another tab.

To reproduce this issue:-

1) Install `pos_restaurant`
2) Duplicate the tab and open the preparation display in one tab
3) In another tab delete the last stage(`complete`) for the above preparation display 
4) In the first tab click any product of an order from the `ready` stage 
5) Now click the `ready` icon of that order
5) At the terminal you will see a traceback

Error:- 

```
IndexError: list index out of range
  File "odoo/http.py", line 2252, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1828, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1833, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2058, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, 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 "home/odoo/src/enterprise/saas-17.1/pos_preparation_display/models/preparation_display_orderline.py", line 51, in send_stricked_line_to_next_stage
    next_stage_id = stage_ids.ids[current_stage_index + 1]
```

When the user clicks on the current stage icon it is supposed to go to the next stage with the help of the current stage index + 1.

But, because the user deleted the next stage it leads to an index error

After applying this will resolve the issue by preventing the user to modify stages
when there is an active session for that preparation display. Which making the code more robust

sentry-5056416790

Forward-Port-Of: odoo/enterprise#59415