This is a follow-up for #69812.

The `distinct` keyword in query ```SELECT distinct res_id FROM mail_message WHERE model=%s```
is not strictly necessary for the correctness of the result, as it will be inserted inside a sub-query that will be able to use the main (model, res_id) index of mail_message.

For example, when the `has_message` field is used in a domain by the website_livechat module[1], the complete query looks like this:
```
SELECT "mail_channel".id FROM "mail_channel"
WHERE  ("mail_channel"."active" = true) AND
       ("mail_channel"."livechat_visitor_id" = 112678387) AND
       ("mail_channel"."livechat_channel_id" = 1) AND
       ("mail_channel"."livechat_active" = true) AND
       ("mail_channel"."id" in (
           SELECT distinct res_id FROM mail_message WHERE model='mail.channel'))
ORDER BY "mail_channel"."create_date" DESC LIMIT 1;
```
In this query, it's obvious that the `distinct` makes zero difference in the results.

However, the presence of the DISTINCT keyword means that PostgreSQL will factor the cost of applying that UNIQUE sort in the query planning, and use MERGE JOIN strategy to avoid sorting multiple times (ok, it could perhaps guess that distinct is useless here, but we asked for it.)

For a database with millions of mail messages, there can easily be millions of hits for the generic "all res_ids for model" query, so the cost of that part will be quite high.

The plan will then look like this (notice the "Unique" step and the cost, 730ms for the index scan + 200ms for the sort):
<details>
  <summary>The query plan when `distinct` is used</summary>

```
                         QUERY PLAN
------------------------------------------------------------------------------
 Limit  (cost=151528.28..151528.29 rows=1 width=12) (actual time=1021.237..1021.239 rows=1 loops=1)
   Output: mail_channel.id, mail_channel.create_date
   Buffers: shared hit=767230
   ->  Sort  (cost=151528.28..151528.29 rows=1 width=12) (actual time=998.799..998.801 rows=1 loops=1)
         Output: mail_channel.id, mail_channel.create_date
         Sort Key: mail_channel.create_date DESC
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=767230
         ->  Merge Join  (cost=3.01..151528.27 rows=1 width=12) (actual time=998.786..998.790 rows=1 loops=1)
               Output: mail_channel.id, mail_channel.create_date
               Inner Unique: true
               Merge Cond: (mail_channel.id = mail_message.res_id)
               Buffers: shared hit=767230
               ->  Sort  (cost=2.44..2.45 rows=1 width=12) (actual time=0.043..0.045 rows=1 loops=1)
                     Output: mail_channel.id, mail_channel.create_date
                     Sort Key: mail_channel.id
                     Sort Method: quicksort  Memory: 25kB
                     Buffers: shared hit=5
                     ->  Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel  (cost=0.41..2.43 rows=1 width=12) (actual time=0.035..0.039 rows=1 loops=1)
                           Output: mail_channel.id, mail_channel.create_date
                           Index Cond: ((mail_channel.livechat_visitor_id = 112678387) AND (mail_channel.livechat_channel_id = 1))
                           Filter: mail_channel.active
                           Buffers: shared hit=5
               ->  Unique  (cost=0.57..143838.35 rows=614997 width=4) (actual time=0.033..993.210 rows=97187 loops=1)
                     Output: mail_message.res_id
                     Buffers: shared hit=767225
                     ->  Index Only Scan using mail_message_model_res_id_idx on public.mail_message  (cost=0.57..129884.36 rows=5581595 width=4) (actual time=0.032..730.233 rows=5586467 loops=1)
                           Output: mail_message.res_id
                           Index Cond: (mail_message.model = 'mail.channel'::text)
                           Heap Fetches: 17
                           Buffers: shared hit=767225
 Planning Time: 0.471 ms
 Execution Time: 1025.410 ms
(37 rows)
```
</details>

Now, if we remove the superfluous `distinct` clause, for the same database, data volume, and result, the plan looks like this:
<details>
  <summary>The query plan when `distinct` is not used</summary>

```
                          QUERY PLAN
-------------------------------------------------------------------------------------
 Limit  (cost=3.44..3.44 rows=1 width=12) (actual time=0.069..0.069 rows=0 loops=1)
   Output: mail_channel.id, mail_channel.create_date
   Buffers: shared hit=8
   ->  Sort  (cost=3.44..3.44 rows=1 width=12) (actual time=0.068..0.068 rows=0 loops=1)
         Output: mail_channel.id, mail_channel.create_date
         Sort Key: mail_channel.create_date DESC
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=8
         ->  Nested Loop Semi Join  (cost=0.98..3.43 rows=1 width=12) (actual time=0.061..0.061 rows=0 loops=1)
               Output: mail_channel.id, mail_channel.create_date
               Buffers: shared hit=8
               ->  Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel  (cost=0.41..2.43 rows=1 width=12) (actual time=0.020..0.020 rows=1 loops=1)
                     Output: mail_channel.id, mail_channel.create_date
                     Index Cond: ((mail_channel.livechat_visitor_id = 117513256) AND (mail_channel.livechat_channel_id = 1))
                     Filter: mail_channel.active
                     Buffers: shared hit=4
               ->  Index Only Scan using mail_message_model_res_id_idx on public.mail_message  (cost=0.57..2.77 rows=10 width=4) (actual time=0.040..0.040 rows=0 loops=1)
                     Output: mail_message.model, mail_message.res_id
                     Index Cond: ((mail_message.model = 'mail.channel'::text) AND (mail_message.res_id = mail_channel.id))
                     Heap Fetches: 0
                     Buffers: shared hit=4
 Planning time: 0.761 ms
 Execution time: 0.095 ms
(23 rows)
```
</details>


Total execution time goes from 1000 ms to 0.1ms.

Reference: introduced by 9a01a2953fa8e8c257568cdcf03f177bf79db35a, coming from #69812, which was fixing a performance problem.

[1] Cfr: https://github.com/odoo/odoo/blob/9b224f35f45876c86dc34934379bfa9e8b3e2160/addons/website_livechat/models/website.py#L40-L44

Forward-Port-Of: odoo/odoo#77993

When validating a receipt, if the product is subcontracted and if the
picking is not fully done, it will be impossible to create a backorder

To reproduce the issue:
1. Create two products P_compo, P_finished
    - Both storable
    - Both tracked by lot
    - P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 4
3. Create a BoM:
    - Product: P_finished
    - BoM type: Subcontracting
    - Subcontractors: a partner P
    - Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
    - Operation Type: Receipt
    - Receive From: P
    - Operations: 4 x P_finished
5. Mark as Todo
6. Inventory > Delivery Orders, find the delivery of P_compo for P and
process it
7. Back to T, Record Components:
    - Quantity: 3/4
    - Set a Lot for P_finished
8. Validate T, Create Backorder

Error: a User Error is raised "You need to supply a Lot/Serial Number
for product: - P_finished"

Since P_finished is subcontracted, a related MO has been generated. On
step 7, when recording the used components, since all P_finished have
not been produced, a second MO is created for the last P_finished.
However, when validating T, both MOs are selected and validated. This is
an error since the user has not yet recorded the used components for the
last MO. The latter should not be validated.

OPW-2582538

Forward-Port-Of: odoo/odoo#78406
Forward-Port-Of: odoo/odoo#78393

~~If both amounts are zero the computed amount is zero.~~
~~If only the denomirator is zero, we let it fail.~~
If the denomirator is zero, we set the computed value to zero.

This issue was observed during upgrade request 41615, with following
traceback.
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/15.0/odoo/service/server.py", line 1246, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 87, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 490, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/15.0/odoo/modules/migration.py", line 180, in migrate_module
    migrate(self.cr, installed_version)
  File "/tmp/tmp3r3s178t/migrations/sale_timesheet_margin/saas~14.5.1.0/end-migrate.py", line 14, in migrate
    util.recompute_fields(cr, "sale.order.line", ["purchase_price"], ids=ids)
  File "/tmp/tmp3r3s178t/migrations/util/orm.py", line 113, in recompute_fields
    records.recompute()
  File "/home/odoo/src/odoo/15.0/odoo/models.py", line 6096, in recompute
    process(field)
  File "/home/odoo/src/odoo/15.0/odoo/models.py", line 6080, in process
    field.recompute(recs)
  File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1243, in recompute
    self.compute_value(recs)
  File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
    getattr(self, field.compute)()
  File "/home/odoo/src/odoo/15.0/addons/sale_timesheet_margin/models/sale_order_line.py", line 21, in _compute_purchase_price
    for amount in group_amount
  File "/home/odoo/src/odoo/15.0/addons/sale_timesheet_margin/models/sale_order_line.py", line 21, in <dictcomp>
    for amount in group_amount
ZeroDivisionError: float division by zero
```

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

Both developments 6c4910a and 7563b44 have been introduced nearly
at the same time in the saas-14.5 version, but the later one is
introducing a side effect that breaks the project sharing feature.

Indeed, before there was one assignee per task (user_id), and now
we can assign several collaborators (user_ids).

As the read on a M2O is just calling the name_get method, it wasn't
an issue.

Now, as it implies to read the res.users (and the res.partner) model,
the assigned users were filtered according to a specific ir.rule
for the portal users:

    <record id="res_partner_rule" model="ir.rule">
        <field name="name">openerp.portal.res.partner</field>
        <field name="model_id" ref="base.model_res_partner"/>
        <field name="groups" eval="[(6,0,[ref('group_openerp_portal')])]"/>
        <field name="domain_force">[('id','child_of',user.commercial_partner_id.id)]</field>
    </record>

This commit re-introduces a correct behavior on the project sharing
feature, by allowing a portal user reading on assignees on task he
has access to, according to the project configuration.

Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>

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

The allocation order is not based on the pickings order

To reproduce the issue:
(Need sale_management,mrp)
1. Create a storable product P
2. Create a BoM for another product dummy_P and add 1xP as component
3. Create and confirm a SO with 1x product P
4. Create and confirm a MO for 1x dummy_P
5. Process a receipt transfer with one P

Error: On the SO, the reserved quantity is still 0. The product has been
reserved for the MO, even if the picking of the SO has been created
first

The default order of several SM is based on the sequence and the
identifier:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26

The default value of the field `sequence` is 10:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26

When creating a SO, the field isn't defined so its default value is used
(10). However, when creating the MO, the field is defined thanks to the
sequence of the related BOM line:
https://github.com/odoo/odoo/blob/864d90a064f093bd6ba24d8464ee491a443a320e/addons/mrp/models/mrp_production.py#L940
Which, in our case, is equal to 1

As a result, when allocating the quantities in `_action_assign`, the
recordset will contain first the SM of the MO and then the SM of the SO.

OPW-2524205

Forward-Port-Of: odoo/odoo#78440
Forward-Port-Of: odoo/odoo#78164

### Expected Behaviour

When a user reply to a mention (on an invoice, a client profile, ...) in a log_note, and this user answers directly in the chatbox, the answer should be considered as an internal discussion, and so be posted as a log_note.

### Observed behaviour

Since V12, when a user reply in the chatbox, the reply is automatically set as a "send-message" reply, which is a issue as the user sends an email to all followers of the discussion while he probably thinks his answer will be visible only by the internal users.

### Reproducibility

This bug can be reproduced following these steps:
1. Declare at least 2 users (A and B) and make sure user A handles notifications in Odoo
2. Log as user B, go anywhere in Odoo and mention the user A in a log_note
3. Log as user A, open the mention notification and reply in the chatbox
4. The answer will be noted as a send-message answer, sending then e-mails to all followers ...

### Problem Root Cause

As long as the V12 isn't supported anymore, we didn't investigate this version. In V13, the issue comes from the fact the chatbox didn't use the same composer class as the discussion module, and then it's not possible to send a log note from the chatbox. In V14, as the discussion module has been totally refactored, the "error" comes from the arbitrary choice to set "false" as the default value of "isLog" on a general message, which implies that the answer from the chatbox is considered as a "send-message" and not as a "log-note".

### Validation
- Wrong behaviour : https://drive.google.com/file/d/1Nx6v27vcxsCkJuifqD9-0T-Xmqc-Khhh/view (from JQU)
- Correct behaviour : cf following screenshot, where we can see that an answer to a mention is now correclty set as log_note (by the bg color in the answer). This has also been validated to make sure a classical chat discussion wasn't impacted, as seen in the screenshot.

![message_to_log](https://user-images.githubusercontent.com/91665701/137698546-fbc6f803-c4fa-448c-a662-e831d7d7b974.png)


### Related tickets

opw-2602712
opw-2659484


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

Forward-Port-Of: odoo/odoo#78520