Requests sent to the server may use an incorrect model (because of a
typo, a module uninstallation, etc). In such case, it leads to
several possible `KeyError` as we try to get the model in the models
of the registry, and the error might not be correctly handled.

Suppose the user loads the page:
`http://localhost:8069/web?id=6&cids=1&model=lorem.ispum&view_type=form`
At some point, js side, it leads to a jsonrpc with route:
`/web/dataset/call_kw/lorem.ipsum/get_views`.
Server side, to process the rule linked to the httprequest, we first
check if the cursor should be a readonly one, line 1821 in:
https://github.com/odoo/odoo/blob/c1d92a0b3be1f125c8fa4061e55b9676c83dd424/odoo/http.py#L1819-L1826
For this route, we use the default method `/web._call_kw_readonly`,
where we get the model class -> `KeyError`. But, as we can see in
the above code, we are not yet in the `_transactioning` method,
where the correct dispatcher is defined.

As a result, for the mentionned use case, when the `KeyError` is
raised, it leads to:
https://github.com/odoo/odoo/blob/c1d92a0b3be1f125c8fa4061e55b9676c83dd424/odoo/http.py#L2264-L2278
First, because of the error class, the `else` block is executed,
where we uselessly print the traceback in the logs (-> we need to
wrap the error in a known one). Second, since the proper dispatcher
is not defined, we use the `HttpDispatcher` and the format of the
answer is therefore incorrect (-> we need to define the dispatcher
earlier)

sentry-4924497911

**Current behavior:**
When enabling the option which specifies that products should
be displayed with their prices including tax, the dialog which
appears when a user is buying tickets for an event has a label
at the top of the window which lists the range of prices for
the available tickets. This price range does not include tax
irrespective of the status of the aforementioned option.

**Expected behavior:**
Displayed prices should adhere to the configuration which has
been selected in the db settings.

**Steps to reproduce:**
1. In the Settings app, give the `Display Product Prices`
     configuration setting the `Tax Included` selection

2. In the Event app, select an event and give at least one
     ticket type a nonzero cost

3. Go to the website, select the event which has the modified
     ticket prices, and click the Register button

4. The label atop the dialog window displays pretax prices

**Cause of the issue:**
The database setting does not affect anything in the XML which
is responsible for displaying this price range label.

**Fix:**
Set the all_prices value to be calculated respective to the
account group that indicates their setting about including or
excluding taxes in display prices.

opw-3734299

Forward-Port-Of: odoo/odoo#153619

Steps to reproduce
==================

In 16.4:
- Go to Accounting > Reconcile 8 items
- Click on the first line on the right
- Edit the label and then press Enter
- Switch to another line

=> Odoo Server Error

Cause of the issue
==================

When pressing Enter, two events are triggered: keydown and change. In the useInputField hook, there is a listener for both of those events, and they both end up calling `record.update` with the current value from the input.

In the relational model, the update is locked inside a mutex.

So the first update (triggered by the keydown) does an onchange. This onchange deletes the current records (Command.CLEAR) and returns new records.

Once this is done, the mutex is released. The second update (triggered by the change event) then tries the same update. Since the value was obtained when queuing for the mutex, it uses the old (now deleted) record.

Solution
========

If the keydown handler was called and it was dirty at the time, isDirty would be reset to false.
So we can simply check if the field is still dirty in the "change" handler.

This was initially done in https://github.com/odoo/odoo/pull/154991 but got lost in a conflict resolution.

opw-3726818

Forward-Port-Of: odoo/odoo#157155
Forward-Port-Of: odoo/odoo#157105

__Current behavior before commit:__
When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can  only login if [`get_current_website`][2] returns the same website as `website_id`.

The issue is that when login with RPC, `dispatch_rpc` is making a [`borrow_request`][3] which hides the `request` object from the RPC layer. This has the consequence that `get_current_website` is not able to retrieve the website based on the url of the request. Thus preventing a user to login via RPC even if the domain used corresponds to the website set in its `website_id` field.

__Description of the fix:__
Add the possibility to retrieve the current website via `threading.current_thread().url` (which is set [here][4]). This way it is possible to know the current website even if `borrow_request` has been used.

opw-3742591

[1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/addons/base/models/res_users.py#L779
[2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944
[3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361
[4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037

Forward-Port-Of: odoo/odoo#157309
Forward-Port-Of: odoo/odoo#154447

Steps to reproduce:
-
- Go to Settings > Technical > Phone > SMS > SMS Templates
- Create a new SMS template that applies to contacts with any content and add context action to save the template (this will allow you to use this template from the contact form view).
- Go to Contacts, select any, click on the gear icon and send an SMS using your new SMS template.

Issue : the Body of the SMS template is not displayed.

Cause of the issue:
-
The send SMS action generates an `sms.composer wizzard` that triggers a call of the `onchange` method to compute the values of the form view of the record from scratch.
The body of the message is computed during the snapshot1 of the onchange of the `sms.composer`
https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L1076 by the `_compute_body` method:
https://github.com/odoo/odoo/blob/72c1a4f96a1219d98ce9b90ee54fd7297b9ab999/addons/sms/wizard/sms_composer.py#L167 To be processed correctly, this computation requires a `template_id` (field of the sms.composer model). This `template_id` information is present in the `self._context` of the onchange as a 'default_template_id'. However, since the template_id is not present in the form view of the sms.composer, it is not part of the `fields_spec` arguments of the onchange and this `default` value is not converted into a value before the snapshot1 at this step:
https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 Prior to Odoo 17.0, this was not a problem as the value was still used from the context the snapshot1. However, this value is now cleaned form the context during the snapshot1:
https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/api.py#L567 https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/tools/misc.py#L1010-L1014 As a result, there is no template_id during the call of the `_compute_body` and the body of the message stays empty.

Fix:
-
In order to compute the body, correctly, we add the template_id as an invisible field of the `sms.composer` form view so that it becomes part of the `fields_spec` arguments of the onchange so that its default value 'default_template_id' is converted into a real value: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 that will be used as an argument of the snapshot1.

opw-3733881

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

Forward-Port-Of: odoo/odoo#154549