## Description
Following d6c6351c7f0b241578121d459943fdf2b305571e, the `ir.rule` related to discuss channels got more elaborated, with more subqueries. When loading an `avatar_128`, in an override of `_find_record_check_access`, a repetitive domain with an `any` operator on the same left leaf. This repetitive domain + the new `ir.rule` lead to a bad postgres plan, leading to a perf regression.

## Fix
We add an `auto_join=True` on `parent_channel_id` to avoid doing an additional nested sub-query coming from the `ir.rule`. This change is safe, as the comodel is the same model as the current one, and an user that has access to a subchannel, should probably already have access to its parent channel.
The other improvement is an optimistic early `super()` call, which should not raise any issue for internal employees, who already should have access to the avatar. In case of an access violation, we fallback on the previous behaviour.

## Benchmark
On a large database, loading an `avatar_128`, cache disabled in browser (simulating a first load) for an internal non-privileged user.

|                      | Timings   |
|----------------------|-----------|
| Before               | 300~400ms |
| `auto_join=True`     | 20~25ms   |
| + `super()` shortcut | 13~23ms   |

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

Steps to reproduce the issue:

1. Install the Repair and Purchase modules
2. Activate multi-steps routes
3. Unarchive the MTO route
4. Change the trigger action for the associated rule to
5. Create a product with the MTO route enabled
6. Create a Repair Order with the  line type and include the product
7. Confirm the Repair Order

Explanation:

A Purchase Order will be created to handle the repair; However, the smart button does not appear at the top of the page. This happens because we are using the wrong linkage from repair to purchase. The current linkage is via , and this field is set when the purchase order
confirmed. We need the link to be established when the Purchase Order is in draft state. The fix is to use
instead.

This commit introduces a minor fix in :

-> Ensuring the correct rule is used by relying on instead of searching by name.

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

In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change.

Steps to reproduce:
-------------------
* Setup a preparation display for a PoS restaurant
* Open PoS and add product A to the order
* Double click on the order line to mark it as skip change
* Add the same product to the order and click on the order button
* At this point the preparation display should only show one product A
* Add another different product B to the order
* Click on the order button
> Observation: The preparation display shows the product B and a second
product A

Why the fix:
------------
Instead of filtering based on the product we filter directly based on the line UUID that is unique and should avoid any further errors

opw-4322597

Commit 1:
[FIX] documents: avoid crashes on inaccessible targets

Reproduce:
1. Create a shortcut for a document you are shared access to.
Say it ends up in My Drive
2. Remove your access to the shortcut's target
3. Go to the folder/section (My Drive) where you have the shortcut
4. Experience an Access Error

Usually, access rights of a document and its shortcuts is synchronized,
so a user can see/edit both or none.
This is not the case with ownership as a user can create a shortcut
to a document they don't own. If they are allowed to view a shortcut
they own when they don't have access to the target anymore, the webclient
crashes on loading target data (e.g. to show previews).

We tested changing the domain of ownership-related access in
user_permission, but it is very costly performance-wise, so this is
our best approach in stable as it affects writes
but not all reads.

Commit 2:

Reproduce:
1. Enable Company 1 and 2
2. Create a document with Company 1
3. Create a shortcut for the document.
4. Change document's company to Company 2
6. Only enable Company 1
4. Experience an Access Error

See previous commit. Syncing company_id with shortcuts allows to 
avoid this.

A test is included.

Task-4236268

Follow-up of https://github.com/odoo/odoo/pull/185583

PR above fixed an issue that results in a traceback when posting a message with `@`mention in multi-company. This happens because a message post with `@`mention notifies the recipients of new message in their inbox, but the computing of this notification was made in the context of the recipient but with `allowed_company_ids` of the person that sends the message. If the recipient does not have access to the `allowed_company_ids` of the sender then this leads to the crash that PR above fixes.

The PR fixed it by removing the `allowed_company_ids` from the context, with `allowed_company_ids=None`. However, some code inspect presence of `ctx.allowed_company_ids` with the following code:

```py
len(self.env.context.get('allowed_company_ids', [])) <= 1
```

Due to `allowed_company_ids` being present as `None`, code attempts to `len(None)` which is invalid thus it crashes.

This commit fixes the issue by passing `[]` as allowed_company_ids. This is semantically the same as passing no `allowed_company_ids` but it prevents crash from the pattern above.

opw-4231529

Forward-Port-Of: odoo/odoo#187393

When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available

Steps to reproduce:
-------------------
* Create a product A with any vendor
* Setup 3 steps receipt and delivery in your warehouse
* Create a sale order for product A
* Receiving steps and purchase order will be created
* Validate the purchase order and all the receiving steps so that there is 1 quantity in the warehouse
* Open PoS, settle the order and ship it later
> Observation: In the PoS order you will see that all receiving steps
  have been created again, and a new purchase order has been created too

Why the fix:
------------
The error was happening because the quantity of the original sale order was still reserved. So when creating the new delivery order there was no quantity available and the whole receiving process was required again. We now make sure to free the quantity before creating the delivery order

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

Forward-Port-Of: odoo/odoo#186484
Forward-Port-Of: odoo/odoo#185469

It defeats the purpose to use `SQL` with f-strings. We observed that if there is an uppercase letter in field names we get an error. Steps to reproduce:

1. Install account_reports
2. Add a manual field `x_M` to `account.move.line`
3. Open Profit and Loss report
4. Group by Analytic.

Error (edited to reduce space):
```
2024-11-13 11:12:53,437 1855548 ERROR test_17.4 odoo.sql_db: bad query:
            -- Create a temporary table, dropping not null constraints because we're not filling those columns
            CREATE TEMPORARY TABLE IF NOT EXISTS analytic_temp_account_move_line () inherits (account_move_line) ON COMMIT DROP;
            ALTER TABLE analytic_temp_account_move_line NO INHERIT account_move_line;
            ALTER TABLE analytic_temp_account_move_line DROP CONSTRAINT IF EXISTS account_move_line_check_amount_currency_balance_sign;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN move_id DROP NOT NULL;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN currency_id DROP NOT NULL;

            INSERT INTO analytic_temp_account_move_line (...)
            SELECT account_move_line.company_id AS "account_move_line.company_id",... to_jsonb(UNNEST(ARRAY[account_analytic_line.account_id, x_plan2_id, x_plan3_id])) AS "account_move_line.analytic_distribution", ... account_move_line.x_M AS "account_move_line.x_M", ...
            FROM account_analytic_line
            LEFT JOIN account_move_line
                ON account_analytic_line.move_line_id = account_move_line.id
            WHERE
                account_analytic_line.general_account_id IS NOT NULL;

            -- Create a supporting index to avoid seq.scans
            CREATE INDEX IF NOT EXISTS analytic_temp_account_move_line__composite_idx ON analytic_temp_account_move_line (analytic_distribution, journal_id, date, company_id);
            -- Update statistics for correct planning
            ANALYZE analytic_temp_account_move_line

ERROR: column account_move_line.x_m does not exist
LINE 10: ... AS "account_move_line.discount_amount_currency", account_mo...
                                                              ^
HINT:  Perhaps you meant to reference the column "account_move_line.x_M".
```

After this patch the same query is:
```
            -- Create a temporary table, dropping not null constraints because we're not filling those columns
            CREATE TEMPORARY TABLE IF NOT EXISTS analytic_temp_account_move_line () inherits (account_move_line) ON COMMIT DROP;
            ALTER TABLE analytic_temp_account_move_line NO INHERIT account_move_line;
            ALTER TABLE analytic_temp_account_move_line DROP CONSTRAINT IF EXISTS account_move_line_check_amount_currency_balance_sign;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN move_id DROP NOT NULL;
            ALTER TABLE analytic_temp_account_move_line ALTER COLUMN currency_id DROP NOT NULL;

            INSERT INTO analytic_temp_account_move_line (...)
            SELECT "account_move_line"."company_id" AS "account_move_line.company_id", ... "account_move_line"."x_M" AS "account_move_line.x_M", ... to_jsonb(UNNEST(ARRAY["account_analytic_line"."account_id", "account_analytic_line"."x_plan2_id", "account_analytic_line"."x_plan3_id"])) AS "account_move_line.analytic_distribution", ...
            FROM account_analytic_line
            LEFT JOIN account_move_line
                ON account_analytic_line.move_line_id = account_move_line.id
            WHERE
                account_analytic_line.general_account_id IS NOT NULL;

            -- Create a supporting index to avoid seq.scans
            CREATE INDEX IF NOT EXISTS analytic_temp_account_move_line__composite_idx ON analytic_temp_account_move_line (analytic_distribution, journal_id, date, company_id);
            -- Update statistics for correct planning
            ANALYZE analytic_temp_account_move_line

```

A similar issue can be triggered if we add a manual field `x_plan2_id` to `account.move.line`:
```
ERROR: column reference "x_plan2_id" is ambiguous
LINE 10: ...nb(UNNEST(ARRAY[account_analytic_line.account_id, x_plan2_id...
```

Both issues are fixed here.

This was observed during upgrades. Mainly due to studio fields being generated with uppercase letters. Still, as shown above, it also fails for manual fields.

Forward-Port-Of: odoo/enterprise#73735

### Steps to reproduce:

- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
  - 1 component: 1 x COMP (tracked by SN)
  - 1 operation: "Register SN on COMP"
  - Add an instruction on your op:
    - type: "Register consumed component"
    - Product To Register: COMP
- Put 2 SN for COMP:
  - SN01 in Stock/Shelf1
  - SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the MO the incorrect location was used

### Cause of the issue:

While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.

### Fix:

We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920

### Note:

Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12
is not embedded in a form view so that the onchange:
https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192
is not triggered by our change of "lot_id".

opw-4149941
---

Forward-Port-Of: odoo/enterprise#73685
Forward-Port-Of: odoo/enterprise#72816