Versions
--------
- 17.0+

Steps
-----
1. Log in as admin;
2. have a user with access to Sales: Own Documents but not Invoicing;
3. assign them as a salesperson to a sales order;
4. create a draft invoice for the order;
5. assign admin as salesperson on the invoice;
6. log in as user;
7. create invoice for the sales order.

Issue
-----
- No existing draft warning is displayed.
- Trying to create a draft results in an access error.

Cause
-----
The wizards starts out as a `newId`. Consequently, its `sale_order_ids` field is also `newId` with the actual order id as its origin. When trying to read the `invoice_ids` of a pseudo-record, it will ignore any records you don't have access to. This is why you don't see an exisiting draft invoice warning.

Then when creating the invoice, the check is done again, but no longer as pseudo-records. Now it does get an invoice to check, and throws an error because it's assigned to a different user.

Solution
--------
Use `_origin.sudo()` to ensure access to the `state` field of the invoices.

opw-4554639

Forward-Port-Of: odoo/odoo#200722

### Steps to reproduce:

- In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes
- Put your warehouse in receipt in 2-steps.
- Create a storable product with a different FR name and a set vendor
- Click on the "Reordering Rules" smart button of the product form
- Create a reordering rule using the buy route for your product
- Add a quantity to reorder > "Order Once"
- Open the associated purchase order in a second window
- Repeat the operation of adding a quantity to reorder > "Order Once" ** A new POL is created instead of being merged to the first one**

### Cause of the issue:

Clicking on Order once will trigger a call of the `_run_pull`. At the end of this call, a stock move will be created and confirmed but the user of the env will be replaced by a SUPERUSER_ID for access rights purposes:
https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L283-L286 However, while the move data's were correctly generated using the language of the user that clicked on order once:
https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L278 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L315 The language that will be used during the action confirm to compare with the picking description in the procurement values will be the language of the new user that is the SUPERUSER_ID in en_US: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_move.py#L1451-L1456 This will lead to a set (and incorrect) `product_description_variants` on that procurement. However, this value will be used to determine in the `_run_buy` if an existing POL could absorb the newly created need: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/stock_rule.py#L131-L135 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/purchase_order_line.py#L341-L350 Since already existing POL will not be found to match the incorrect `product_description_variants` a new one will be created on that same PO.

### Fix:

We do not rely on the language of the user in case it is the SUPERUSER_ID.

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

Forward-Port-Of: odoo/odoo#198415
Forward-Port-Of: odoo/odoo#192751

### Issue:

Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1 rather than COMP2.

### Steps to reproduce:

- In the settings enable Multi-steps routes
- Have two companies: COMP1 and COMP2
- Create a routes without set companies with 3 rules:
  - rule 1 (comp1): - Pull from Virtual Locations/Inter-company transit to WH1/Stock supply method: Trigger an other rule.
  - rule 2 (comp2):  - Pull from  WH2/Stock to Virtual Locations/Inter-company transit, supply method: Trigger an other rule.
  - rule 3 (comp2): - Buy from Partner/vendors to WH2/Stock using a custom operation type towards Virtual Locations/Inter-company transit.
- Create a storable product with both routes set.
- With COMP2: set a vendor on that product.
- In COMP1, your product > Reordering rules create a new rule using the COMP1 route to replenish WH1/Stock.
- With both COMP1 and COMP2 as active order once.
> The PO could not find a vendor as it looked for suppliers in COMP1 and if such a supplier was set in COMP1, the PO would be created in COMP1.

### Cause of the issue:

While the rule of COMP2 is found and used to run the procurment here: https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_rule.py#L484 the procurement was created and is linked to the company owning the move creating the demand (that is COMP1):
https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_move.py#L1494-L1498 However, the `company_id` used in the `_run_buy` notably for the data's of the PO will be the company linked to the procurement rather than the company linked to the buy rule. Since the buy rule should generate a purchase order in company it uses, this is incorrect.

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

Forward-Port-Of: odoo/odoo#199807

Backport of https://github.com/odoo/odoo/pull/199212

Runbot may be red due to tours ending while portal chatter is lazy-loading.
We don't care of lazy-loading of portal chatter that hasn't ended, the tour passes and that's what matters.

ORIGINAL MESSAGE:

Before this commit, short portal and website tours that open a page with portal chatter may crash with following error:

```
Error received after termination: AssetsLoadingError: The loading of http://127.0.0.1:8069/web/bundle/portal.assets_chatter_style?lang=en_US&website_id=1 failed
```

This happens because the tour is so short and doesn't assert loading of portal chatter that the tour ends while portal chatter hasn't been loaded. The tour termination forces abort of ongoing lazy-loading such as portal chatter, which results in the crash above.

This commit fixes the issue by silently catching the error in this very specific case that lazy-loading has been aborted by browser page reload or closing, which is precisely the case with tour. The crash is not relevant in that case, in practice the crash is intended to detect programming errors.

runbot-114302

Forward-Port-Of: odoo/odoo#200810

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#199086
Forward-Port-Of: odoo/odoo#196719

\+ tests update in documents_approval

Fix owner edit role member after copy or creating inside a
folder, including while specifying access_ids.

Allow client code to add members to the default members added by
the base logic of documents (owner's log) and folders inherited
values => Fix HR Payroll Employee Declaration where members of the
payroll folder would not have access to the generated documents.

The paradigm is:
* The owner should always have a "document.access" record created
* It should be possible to add a member in addition to the inherited
  ones.
* If one passes values for a member when creating, it should override
  the default value for that partner.
* If access_ids is passed as `False`, it should prevent inheriting
  access (but not prevent a role=False record for owner).
* Follow-up of https://github.com/odoo/enterprise/pull/77783, there is no need to enforce
  logic for owner's `documents.access` role as the owner is
  basically an empowered editor.

Additionally, make sure that
 * No membership (document.access with role) is created for odoobot
 * The access of owner is not shown on the permission panel

Task-4593290

Forward-Port-Of: odoo/enterprise#79915

### Issue:
- When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company.

### Steps to reproduce:
- In a multi-company environment say we have companies A(id: 1) and B(id: 2), and the user default company is A. (he has access to both).
- Create 2 user-defined defaults for the field : `documents.document.company_id`, setting value to 1 for company A and 2 for company B.
- Create a document using company B, the document's `company_id` will be set to company B which is wrong.

### Solution:
- in controllers `request.env.company` always returns the user's default company, so whenever we upload a document (call the `documents_upload` controller), `documents.document` create assumes that the current company is the user's default company.
- To fix this, we add the `allowed_company_ids` to the upload request params in the JS `DocumentService` and  we intercept in the python controller and set the `allowed_company_ids` context on the request to make sure create will use the current company instead.

OPW-4507424

Forward-Port-Of: odoo/enterprise#80060