### Steps to reproduce:

- Create a PO:
  - 1 x storable product 1
  - 1 x storable product 2
- Confirm the PO
- Change the quantity of the PO line of product 1 to 0 (this modifies the associated delivery accordingly)
- Click on the customer to open the res.partner form
- Click on the "On-Time Rate" smart button

#### > Traceback: psycopg2.errors.DivisionByZero

### Cause of the issue:

Clicking on that smart button will call the "_read_group" method and the following sql expression will be added to the associated query: https://github.com/odoo/odoo/blob/b4620c123b753caf2b77472a8d6c42d767471c53/addons/purchase_stock/report/vendor_delay_report.py#L57-L60 The error is therefore rasied because the SUM(qty_total) associated to product 1 was reset to 0 because of our change on the PO line.

### Fix:

Since SUM(qty_total) of 0 signifies that no units of that product was not expected to be delivered for that customer. As such they should be removed from the products whose "On-Time Rate" is computed from the vendor.delay.report's.

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

Forward-Port-Of: odoo/odoo#162632

**Current behavior:**
In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers.

**Expected behavior:**
The current status of a package should not affect the accessibility of a company's picking history.

**Steps to reproduce:**
1. Setup 2 companies, for both:
        Enable packages
        Enable stock warehouse locations
        Enable multi-step routes -> set their in/out routes to 3-step (pick, pack, ship)

2. Create a reusable box type package, don't assign it to either company

3. In CompanyA, create a delivery using the reusable package and complete it so the package is fully emptied and ready to be reused

4. Switch to CompanyB, create a picking (any kind) using the same reusable box -don't finish the transfer- then switch back to CompanyA

5. Try to view Inventory transfers -> AccessError

**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method which is called on-demand when we try to open the transfers tree view. We will eventually look at packages from the picking that used the reusable package (which now 'belongs' to another company) and raise the AccessError.

**Fix:**
Use sudo() to read package records in the iteration over picking records.

We are only reading from pickings which belong to the current company, which makes the access check for the package records redundant (and as we see here problematic).

opw-3813917

Forward-Port-Of: odoo/odoo#166575
Forward-Port-Of: odoo/odoo#164677

Issue:
======
The label of link doesn't auto save.

Steps to reproduce the issue:
=============================
- Go to email marketing
- Add text block
- Select some text and convert it to link
- Change the label of link from the link tools
- Click on the top , outside the editable
- The label sets back to it's original value

Origin of the issue:
====================
`onSelectionChange` is called from the flow of `obeserverApply` which
calls `deselectTable` here [1] and it deactivate the observer which
clears `this.observerTimout` so `historyStep` don't get caled.

Solution:
=========
- We don't unactivate the observer when there are no `td` elements to
  process.


[1]: https://github.com/odoo/odoo/blob/saas-16.3/addons/web_editor/static/src/js/editor/odoo-editor/src/OdooEditor.js#3931

---

Issue:
======
Traceback after discard mass mailing with selection

Steps to reproduce the issue:
=============================
- Create a new mass mailing
- Choose the welcome template
- Click outside the editable
- Select the first paragraph in the template such that the toolbar
  appears
- discard the record
- traceback

Origin of the issue:
=====================
The flow goes as follows, create a new mass mailing, click outside the
editable will trigger commitChanges, now we click again inside the
editable, `activeSnippet` is called which will add some item to the
list of snippetEditors in `SnippetsMenu`.

Now clicking on discard will goes as follows, `onWillUnmount` will be
called and we find the record dirty because the commited changes have
already been cleared from `record.data` so we have 2 flows going in
parallel , one for the commitChanges and one for the destroy which
will be called in this order while running, commitChanges -> destroy
-> observerUnactive -> observerFlush -> observerApply -> contentChanged
-> updateCurrentSnippetEditorOverlay -> cover ->
`ownerDocument.defaultView` but the docuemnt doesn't have a window
anymore so its value is null thus the traceback.

Solutions:
==========
We add check on the default view to make sure it's not null before
accessing it.


task-3857016

Forward-Port-Of: odoo/odoo#166233
Forward-Port-Of: odoo/odoo#161845