*: 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

## Short functional explanation of the error
When printing a reception report containing a lot of products, the top row of the pages after the first one is overlapped with its corresponding header in the resulting PDF.

## Reproduction Steps
1. Open the settings. In the inventory section, enable "Reception Report".
2. Create a new quotation and add at least 40 different products. Each product should have at least 1 copy in stock, and the quantity to order must be greater than the quantity we have of this product in stock.
3. Confirm the sales order.
4. Create a new purchase order and add the exact same products you added in the quotation.
5. Confirm the order and click on the "Recept" smart button.
6. Click on the "Allocation" smart button and click on the "Assign all" gray button.
7. Click on print and open the PDF once it finishes downloading.

### Expected behavior
Each row (corresponding to the reception of a product) and its corresponding header is printed properly,  regardless of how many pages constitute the report.

### Unexpected behavior
The PDF has more than one page, and on the top of the second page, the product row is overlapped with the header of its corresponding section.

## Origin of the issue
It comes from an issue with WKHtmltopdf itself:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1524
The report uses the "thead" tag for the headers. However, in some cases, when the header is linked to a table dynamically (with for-each, for
 example), WebKit ignores or breaks the "Thead" behavior.

## Explanation of the fix
I override the default behavior of thead, which repeats the header automatically at each new page, with a new style. Now, the "Thead" special behavior is ignored and treated like ordinary lines. The header isn't shown at each new page anymore, avoiding the overlapping of product rows.


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

Forward-Port-Of: odoo/odoo#215398

## Short functional explanation of the error
When selling items in the point of sale module with an invoice, when we check said invoice in the backend, the customer reference field is empty.

## Reproduction Steps
1. Go to Point of sale and open a shop interface. Add a random item to the basket and select a customer.
2. Click on payment, then check Invoice, select a payment method, and Validate.
3. Click on the hamburger menu on the top right and click on Backend.
4. Hover the box of the shop you opened with your mouse. In the top right corner of the box should appear a 3-dot menu. Click on it and click on Sessions.
5. Click on the latest session ID. On the top of the page, click on the "Orders" smart button.
6. Click on the order you just finalized. On the top of the page click on the "Invoice" smart button.
7. Click on "Other info" tab.

### Expected behavior
The Customer Reference field should be filled with the name of the order.

### Unexpected behavior
The Customer Reference field is left empty.

## Origin of the issue
When setting the values for the invoice, the field 'Ref' was absent.

opw-4732492

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

Forward-Port-Of: odoo/odoo#218158

**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.

When Debug requests is enable on the whatsapp business account and
user replies with the file, a traceback will appear.

Steps to reproduce the error:
- Install ``whatsapp`` and ``contacts``
- Create a whatsapp business account > Enable Debug requests
- Create a contact > Add a phone number > send whatsapp message with any whatsapp template
- Now reply with the file(ex. pdf or image) in message from the contact's whatsapp.
- Traceback in terminal

Traceback:
``ValueError: A string literal cannot contain NUL (0x00) characters.``

https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166
Here, ``message`` contains NUL (0x00) characters because user replies with
the file, value for the ``message`` comes from the below response.

response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57

Here, ``res.text`` contains NUL (0x00) characters.
So, it will lead to the above traceback.

sentry-6314521165

Forward-Port-Of: odoo/enterprise#83274

**PROBLEM**
In the accounting app, when selecting multiples customers, if one of them doesn't have a name, the cron sending the report will traceback.

**STEP TO REPRODUCE**
- On a clean db, install the account_reports module
- From the accounting app, create a new company customer (Customers/Customers)
- From that new company customer form view, add a new contact of type "other" and don't specify a name for it.
- Create an invoice for the company
- From the customer list view, select all, and trigger the action "Open Customer Statements"
- Send -> Print and Send
- Check the console, the cron task should traceback on the template

**CAUSE**
In accout_report.py, we get the name of each selected partners, and we don't check if the name doesn't exist. In the template `pdf_export_filters`, we try to join all the name in a string, it fails because one of the name isn't a string (its value is False because it doesn't exist on the partner record).

**FIX**
When getting the partners names, filter out the partners without names.

opw-4916660

Forward-Port-Of: odoo/enterprise#90154

Currently, an error occurs when clear the date_to field from an already created record.

Steps to Reproduce:
 - Install the `sale_commission` module.
 - Go to `Commission Plans` and create a record.
 - Now, clear the `date_from` field and save.

`TypeError: '>' not supported between instances of 'bool' and 'datetime.date'`

This error occurs when we clear the date_to field from an already created record. The error started occurring after
https://github.com/odoo/enterprise/commit/926c8f041b51a04f0153be27cfcc8658a07be5b0 this commit that introduced the daterange widget for the date_from field. And when we clear the date_to field and try to save, it triggers the constraint [1] and raises the error.

[1] https://github.com/odoo/enterprise/blob/377321fd7e7b1b2026734b75c79c74c8947e2e6c/sale_commission/model/commission_plan.py#L64

This commit ensures that the record is saved only if the date_to field is also present in the record.

sentry-6710699656

Forward-Port-Of: odoo/enterprise#88769