*: website_livechat. Before this PR, a `mail.channel` record would have been created before any user interaction. Since the introduction of the welcome bot, this issue has gotten worse. Indeed, any user accessing a page with the bot enabled created a useless channel. Before 15.3, around 15k channels were created each month, after 15.3, 300-500k channels are created each month, most of them empty channels whom creation could have been avoided. Forward-Port-Of: odoo/odoo#108460 Forward-Port

*: website_livechat.

Before this PR, a `mail.channel` record would have been created before any user interaction. Since the introduction of the welcome bot, this issue has gotten worse. Indeed, any user accessing a page with the bot enabled created a useless channel.

Before 15.3, around 15k channels were created each month, after 15.3, 300-500k channels are created each month, most of them empty channels whom creation could have been avoided.

Forward-Port-Of: odoo/odoo#108460
Forward-Port-Of: odoo/odoo#108052

*: website When dragging inner contents, dropzones appear in the Carousel snippet, allowing to drop them directly in the element with the `row` class, where it should not be the case. This is due to the `content` class present on these elements and to the drop-in rule for inner contents that allows them to be dropped in elements having this class. This commit fixes this issue: - in stable: as the XML files cannot be modified, the drop-in rule is patched in JS to exclude the elements havin

*: website

When dragging inner contents, dropzones appear in the Carousel snippet, allowing to drop them directly in the element with the `row` class, where it should not be the case. This is due to the `content` class present on these elements and to the drop-in rule for inner contents that allows them to be dropped in elements having this class.

This commit fixes this issue:
- in stable: as the XML files cannot be modified, the drop-in rule is patched in JS to exclude the elements having both the `content` and `row` classes.

- in master: it removes the `content` classes from the rows of the Carousel snippet. It also removes this class from the drop-in rule, as only Carousel was concerned by it.

See [1] for the following of this fix in design-themes.

[1]: https://github.com/odoo/design-themes/pull/603

task-3011192

Forward-Port-Of: odoo/odoo#108560
Forward-Port-Of: odoo/odoo#102696

Before [1], the bus was started lazily: either as a consequence of the addition of a channel to listen to or by manually calling the `startPolling` method. Before this commit, the websocket would have been started as soon as the bus service starts which degrades performances. This PR fixes the issue by re-introducing the same mechanism as before that is by starting the websocket either by calling manually the `start` method of the bus service or automatically when adding a channel. [1]:

Before [1], the bus was started lazily: either as a consequence of the addition of a channel to listen to or by manually calling the `startPolling` method.

Before this commit, the websocket would have been started as soon as the bus service starts which degrades performances.

This PR fixes the issue by re-introducing the same mechanism as before that is by starting the websocket either by calling manually the `start` method of the bus service or automatically when adding a channel.

[1]: odoo#75510

Forward-Port-Of: odoo/odoo#108726

The "website_gray_color_palette" tour recently failed 4 times during staging build on runbot, out of those 4 caught times, it seems that: A) 3 were because the last step was marked as failed too soon (screenshots and logs seem to indicate the editor was still loading). B) 1 was because of a "random" asset error (traceback when lazy loading the editor JS). The cause of (B) was not found and should be later investigated if seen again. This commit tries to avoid (A) which is probab

The "website_gray_color_palette" tour recently failed 4 times during staging build on runbot, out of those 4 caught times, it seems that:

A) 3 were because the last step was marked as failed too soon
   (screenshots and logs seem to indicate the editor was still loading).

B) 1 was because of a "random" asset error (traceback when lazy loading
   the editor JS).

The cause of (B) was not found and should be later investigated if seen again. This commit tries to avoid (A) which is probably related to a known issue: when the website iframe has to reload it may sometimes take more time than is allowed by the default timeout of tour steps. Some improvements regarding that will be made at [1] and probably by further PR after that (improving the editor loading speed in general).

Meanwhile, this commit reviews the tour to not save the editor as it was actually not needed in this tour (nothing has to be saved).

[1]: https://github.com/odoo/odoo/pull/100122

runbot-14112

Forward-Port-Of: odoo/odoo#108742

Commit [1] which occurred in 13.X for the upcoming release of the 14.0 version introduced a "No column" option for snippets whose only column was removed but that we wanted having the possibility to switch to a multi-columns layout. At the time: Title, Text and Cover snippets. That "None" option was meant to be hidden (as it was at the time) for other snippets already in a multi-columns layout. Indeed the "No column" and "1 column" options are very similar: "No column" is just an optimization

Commit [1] which occurred in 13.X for the upcoming release of the 14.0 version introduced a "No column" option for snippets whose only column was removed but that we wanted having the possibility to switch to a multi-columns layout. At the time: Title, Text and Cover snippets.

That "None" option was meant to be hidden (as it was at the time) for other snippets already in a multi-columns layout. Indeed the "No column" and "1 column" options are very similar: "No column" is just an optimization for experienced users.

The problem here was that [2] broke the behavior. Indeed [1] marked the code in charge to hide that "No column" option as "To improve" as the system was limited to do that at the time... [2] actually improved the system to allow hiding sub-widgets, but did not adapt [1], making the "No column" option always visible.

While working and not harmful, that "No column" option may be confusing as at best you don't see the difference with the "One column" option and at worst, removing the column removes nice style that you cannot restore by choosing a multi-column layout again afterwards.

While not entirely stable (in the end we never released a major version where [1] was working as intended), this commit restores the idea behind [1] anyway to avoid further confusion and tickets. Choosing "One column" instead of "None" most of the time leads to a better UX anyway.

[1]: https://github.com/odoo/odoo/commit/b293ccc7c3c5ca9a55092afd2e4a7b88c7b93fc8
[2]: https://github.com/odoo/odoo/commit/ecefd51b63ed8c933243b4a2d26381d05ac288d2

Related to task-3106301

Forward-Port-Of: odoo/odoo#108743
Forward-Port-Of: odoo/odoo#108739

Since [1] the blog tag option was not shown in the website editor option's panel anymore. Because the tag is not in an editable element and the `data-no-check` was not specified. After this commit the blog tag option is restored. This PR also aligns the m2m fields label to the top. [1]: https://github.com/odoo/odoo/commit/86e3bb5e24c2d125ec4ec84ac788601c63182d0f task-2811746 Forward-Port-Of: odoo/odoo#108686 Forward-Port-Of: odoo/odoo#88133

Since [1] the blog tag option was not shown in the website editor
option's panel anymore. Because the tag is not in an editable element
and the `data-no-check` was not specified.

After this commit the blog tag option is restored.
This PR also aligns the m2m fields label to the top.

[1]: https://github.com/odoo/odoo/commit/86e3bb5e24c2d125ec4ec84ac788601c63182d0f

task-2811746

Forward-Port-Of: odoo/odoo#108686
Forward-Port-Of: odoo/odoo#88133

Client ID is used in res_config_settings both for `auth_oauth_google_client_id` and `pos_l10n_de_fiskaly_client_id`. Changes the label of `pos_l10n_de_fiskaly_client_id` to avoid the warning ``` Two fields (pos_l10n_de_fiskaly_client_id, auth_oauth_google_client_id) of res.config.settings() have the same label: Client ID. [Modules: l10n_de_pos_cert and auth_oauth] ``` Forward-Port-Of: odoo/enterprise#35276

Client ID is used in res_config_settings both for
`auth_oauth_google_client_id` and `pos_l10n_de_fiskaly_client_id`.

Changes the label of `pos_l10n_de_fiskaly_client_id` to avoid the warning

``` 
   Two fields (pos_l10n_de_fiskaly_client_id, auth_oauth_google_client_id) of res.config.settings() have the same label: Client ID. [Modules: l10n_de_pos_cert and auth_oauth]
 ```

Forward-Port-Of: odoo/enterprise#35276

Forward-Port-Of: odoo/enterprise#35183

Forward-Port-Of: odoo/enterprise#35183

The Swiss federal tax authority provides data on exchange rates daily in an xml format. The endpoint for xml is changing so the url in the code must be updated to match the new endpoint. task-id: 3112347 Forward-Port-Of: odoo/enterprise#35259 Forward-Port-Of: odoo/enterprise#35252

The Swiss federal tax authority provides data on exchange rates daily in an xml format.

The endpoint for xml is changing so the url in the code must be updated to match the new endpoint.

task-id: 3112347

Forward-Port-Of: odoo/enterprise#35259
Forward-Port-Of: odoo/enterprise#35252

The util method to get the unsplash key was removed with [1], but has been restored in [2] because it was still needed for internal reason [3]. This commit replaces the usage of ICP get_param by this util method, and fixes the "add random cover" feature not working on the SaaS. [1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c [2]: https://github.com/odoo/odoo/commit/a48692d105dc2321b1799f5ef1013c022efbb7c3 [3]: https://github.com/odoo/internal/commit/de35

The util method to get the unsplash key was removed with [1], but has been restored in [2] because it was still needed for internal reason [3].

This commit replaces the usage of ICP get_param by this util method, and fixes the "add random cover" feature not working on the SaaS.

[1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c
[2]: https://github.com/odoo/odoo/commit/a48692d105dc2321b1799f5ef1013c022efbb7c3
[3]: https://github.com/odoo/internal/commit/de3532b3640793049d356c659df0497edd9a7fc6

Task-3112386

Forward-Port-Of: odoo/enterprise#35264

### Setup - DB with main company on the US - account_taxcloud, ecommerce, sales, and website_sale_coupon installed - Full address (US) set on the company - Taxcloud activated (with test credentials*) - Taxcloud fiscal position set as “detect automatically” - Have a product available in your eShop ### Steps to reproduce - in a new incognito window, go to the shop, put a product in your shopping cart and process to check out - Fill in an Americana address. It's important to have an addr

### Setup
- DB with main company on the US
- account_taxcloud, ecommerce, sales, and website_sale_coupon installed
- Full address (US) set on the company
- Taxcloud activated (with test credentials*)
- Taxcloud fiscal position set as “detect automatically”
- Have a product available in your eShop

### Steps to reproduce
- in a new incognito window, go to the shop, put a product in your shopping cart and process to check out
- Fill in an Americana address. It's important to have an address that makes sense and whose state is supported by taxcloud. You can use the following:
  - City: Gaylord
  - Postcode: 55334
  - Country: United States
  - State: Minnesota
- click next, and you'll be redirected to a payment page
- now open the shopping cart in a new tab

If you go to the sales app and look at the quotation associated with your session, you should see that the taxes have been removed.  However, since you already have a payment page open, you can complete the checkout without having to pay the taxes.

### Cause
In the `website_sale_coupon` module, `SaleOrder.recompute_coupon_lines()` is called when the user goes to the shopping cart. https://github.com/odoo/odoo/blob/a3d543d2ac266ea7db1e1c2c60617963d4005a5a/addons/website_sale_coupon/controllers/main.py#L25-L28
However, the following line in `SaleOrder.recompute_coupon_lines()` clears the tax. https://github.com/odoo/enterprise/blob/892e19ec2f805af6696008ddeb783d49770a54f8/sale_coupon_taxcloud/models/sale_order.py#L31 In most cases this is fine since the taxes are recomputed when the users go to the payment page.  But in this case, the user already has a payment page open, so the tax is never recomputed.



opw-2815397

Forward-Port-Of: odoo/enterprise#35241
Forward-Port-Of: odoo/enterprise#32428