*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#220292
Forward-Port-Of: odoo/odoo#219389

**Current behavior:**
Creating a purchase order in a foreign currency and billing the
product prior to reception will produce 2 issues:
A) The bill line for the product will only make a conversion of
1 single unit of the product with the defined currency exchange
rate, making the amount on the line incorrect when qty > 1

B) When the receipt is finally validated, there will be an
unwanted exchange difference on the journal items generated due
to asymmetrical rounding for the bill AMLs and receipt valuation
AMLs

**Expected behavior:**
Correct bill line currency amounts and symmetric rounding.

**Steps to reproduce:**
1. Set the company currenct to IQD, make a product invoiced on
ordered qty, for sake of example set cost to 500 IQD

2. Create a currency exchange record to USD with a company rate
of `0.00756`

3. Create a PO for 13 of the product created in step 1, with a
discount of 1%

4. Confirm the PO and create the bill -> post it

* Issue A) look at invoice line, see only 1 unit in the
converted currency amount is accounted for by the `balance`

5) Receive the product -> look at the journal items generated
and see that there is a diff of 0.185 IQD

**Cause of the issue:**
A) commit: 90158f6 added a method to try and calculate an AML
balance from its purchase line values, but mistakenly is using
`qty_received` instead of `qty_to_invoice` which explains why
this issue only presents for the bill-before-receipt flow

B) commit: 9f046d5 is using `round=False` context for
`AccountTax.compute_all()` when the expected key is `round_base`

**Fix:**
A) Replace `qty_received or 1` with `qty_to_invoice`
* Also make the test added in 90158f6 more robust

B) Add `round_base=False` alongside the `round` key (not
removing as that existing one could have become expected in this
context)

opw-4689170

Forward-Port-Of: odoo/odoo#216898
Forward-Port-Of: odoo/odoo#205850

**Current behavior before PR:**

**Issue 1:**

- Paste a content with multiple `<li>` elements without `ol/ul` tag, each `<li>` having a paragraph element inside.
- Try to create a list from these elements.
- List is created with wrong element structure.

The problem occurs because when pasting multiple `<li>` elements without an `<ol>/<ul>` tag, `sanitizeNode` replaces existing `<li>` elements with new `<p>` elements. Since each `<li>` already contains a `<p>`, this results in paragraphs being nested inside other paragraphs. As a result, creating the list from these paragraphs leads to an incorrect structure.

**Issue 2:**

If there are multiple paragraph selected along with newline character nodes `(\n)`, it is not possible to remove bold or italic
format from selected content using toolbar. The issue happens because `isSelectionFormat` method fails to give correct value if traversed nodes contains one or more newline `(\n)` characters.


**Desired behavior after PR is merged:**

**Issue 1:**

Now, if an `<li>` contains a `<p>`, the `<li>` is unwrapped instead of creating a new paragraph, resulting in a correct element structure when creating a list.

**Issue 2:**

Now, `\n` nodes are filtered from traversed nodes so that format can be removed from selected content.

task-4752385

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

Forward-Port-Of: odoo/odoo#217361
Forward-Port-Of: odoo/odoo#208127

**PROBLEM**
1. When setting up a product with vendor that sell the product in different packaging, when triggering the reorder, the PO use the stock UoM instead of the replenishement UoM.
2. Once the first issue is fixed, we can notice the packaging quantity in the picking order is not exactly what it should be (rounding error of 0.01).
3. Once the first issue is fixed, there is a failing test concerning the manufacture procurement route.

**STEP TO REPRODUCE**
1. activate the UoM and packaging option.
2. create a product with a vendor that sells it in a packaging.
3. create a reordering rule with the replenishement UoM being the packaging unit.
4. trigger the reordering, notice the PO doesn't use the right unit and the picking doesn't use the right packaging.
(Same steps to reproduce, just revert my change on stock_move.py before)
(To reproduce the 3rd issue, run the test in odoo/addons/sale_mrp/tests/test_sale_mrp_procurement.py)

**CAUSE**
The procurement for the reordering rule is always created with the stock UoM.
The `_compute_packaging_uom_qty` method doesn't specify the rounding_method to use when converting from the product uom to the replenishment uom.
By default, it uses the 'UP' method.
The _run_manufacture method has a bug: when there is a new procurement for a product that has already a mo opened, it will try to update the mo quantity.
To do so, it calculate a new quantity, by adding the previous quantity and the procurement quantity, but it assumes the quantity is in the product default uom which is not always the case (for example, when there is a replenishment UoM set on the reordering rule).

**FIX**
1. If a remplenishement uom exists on the reordering rule, we create the replenishement with this unit instead of the stock one.
2. Use the 'HALF-UP' rounding method, to reduce the rounding error.
3. Converting the procurement quantity into the product default UoM before computing the new mo quantity.

opw-4858992

Currently, an error occurs when sending invoices in bulk.

Steps to Reproduce:
 - Install the `account` module.
 - Go to `Email Templates` and open `Invoice: Sending`.
 - In the `Email Configuration`, uncheck `Default Recipients` and enter 
   `demo@gmail.com` in the `cc` field.
 - Go to `Invoices`.
 - Select multiple invoices and click `Send`.

`KeyError: <NewId origin=33>`

This error occurs when sending invoices in bulk. As mentioned in commit https://github.com/odoo/odoo/commit/058d324855a6e2fe3df51386aa153d46419766bf,
the issue was introduced in commit https://github.com/odoo/odoo/commit/39d1907d77ca9c88431e7e9dc9e8c938c79a2987, where the _compute_alerts method attempts 
to set an alert in the wizard. However,since this is a computed field, the 
wizard record has a NewId and calls the method with a transient record [1]. 
When trying to access record.id, it returns a NewId [2], and later, when this 
NewId is used as a res_id [3],it raises a KeyError.

[1]-https://github.com/odoo/odoo/blob/aff5f006d5b1996ea3ecc67998067cd0e292cf2a/addons/account/wizard/account_move_send_batch_wizard.py#L63

[2]- https://github.com/odoo/odoo/blob/c70bca77d0447b005b3898e1861facc2828475fc/addons/mail/models/mail_thread.py#L2037

[3]- https://github.com/odoo/odoo/blob/c70bca77d0447b005b3898e1861facc2828475fc/addons/mail/models/mail_thread.py#L2084

This commit fixes the above issue by using move_ids._origin, ensuring that the method is 
always called with real records, and removes the changes from the previous commit https://github.com/odoo/odoo/commit/058d324855a6e2fe3df51386aa153d46419766bf.

sentry-6562659542


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

Forward-Port-Of: odoo/odoo#217730

Issue:
The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created.

Solution:
Create it in the post init hook.

Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed.

Also, make the code a little bit more robust:
* instead of mixing "default misc journal" and vat return journal logic, just use one logic
* the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one
* the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any.
* Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook.