Before this commit, only whitelisted fields would be updated on cow views
during a module update.
A field would be whitelisted if he had the same value than the original view,
see it as a heuristic to not write on modified fields.

But `inherit_id` is not that simple, even if the cow view has a different value
than its original view, it doesn't mean it was modified by the user, it is just
because of the cow mechanism that assigned a copied view as inherit_id, which
is just a copy ofthe original one.

We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
the same.

In practice, it means that cow'd views did not receive the `inherit_id` updates
as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
where `portal.my_account_link` had its `inherit_id` changed from
`portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059:

Considering a module update changing `inherit_id` of D from A to B, the
following use cases are expected. Without this fix, D' never move:

CASE 1
  A    A'   B                      A    A'   B
  |    |                 =>                 / \
  D    D'                                  D   D'

CASE 2
  A    A'   B    B'               A    A'   B   B'
  |    |                 =>                 |   |
  D    D'                                   D   D'

CASE 3
    A    B                        A    B
   / \                   =>           / \
  D   D'                             D   D'

CASE 4
    A    B    B'                  A    B   B'
   / \                   =>            |   |
  D   D'                               D   D'

Opw: 2422773
Opw: 2422727
Opw: 2422770
Opw: 2423406
Opw: 2423859

X-original-commit: 2951ed681aa5e31563e501de691716806ddb46bd

Before this commit, once you install website_* module, the ir.actions.todo from
the installed module was overidded by the 'choose a theme' action.

Now, when we consume this ir_act_todo, we re-open the open_menu that contains
most of the time the expected next action from new module installed.

Since we can also install module from the '+ new' button, in frontend, we
considere that it first step of tour is to click on it, it is already done and
we skip it.

Install website_event
Before:
   -> not redirected to /event (the ir.action.todo)
   -> no tour, if you don't click manually on '+ new'

After:
    -> you are redirected to /event
    -> you can launch tour from '+ new' if you are already on the new panel,
       start direclty to the second step 'create event'

This commit redirect the user to the website in the edit mode once a theme has
been selected.

task-2172208

Before this commit, some code was resetting some default website config
on theme change.

Problem 1:
This was not done when *removing* a theme. Thus when you wanted to go
back to a default website theme, you were not properly reset to the
default theme config. This could actually crash: some themes define
more fonts than others; so if you selected font 13 in one theme then
removed the theme, the default one would crash if not properly reset
as font 13 would not exist.

Problem 2:
It was done for every theme dependency, making theme change slower for
no reason.

Problem 3 (theorically, not tested):
The current code worked by chance as it called the website
'make_scss_customization' method without giving any website to it. It
actually worked by fallback on the right website in normal user cases
(user in the context of installing a theme on a specific website) but
may not be working when trying to install a theme on a different website
calling those functions from custom code.

Now, a dedicated method is there for config reset and is called at the
correct place with the right website in the context.

closes odoo/odoo#53743

X-original-commit: 7307d696449ea2b7a231b0b9087e64f6bbf65d26
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This reverts commit fdd4a143f2148ec5f4aeea80fecd3138fea95dc6.

See discussion in #51969

closes odoo/odoo#52028

X-original-commit: 0e602cc0ac295621864b50509f78bd5de1e61718
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

A view is marked as `arch_updated` if `arch` is being written on it
and `install_filename` is not in the context:
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/odoo/addons/base/models/ir_ui_view.py#L460-L461

When a view is being updated from a `theme.ir.ui.view` through `_update_records`
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L29
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L92
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L208
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L168

we can basically consider it comes from a data file,
the template is updated, and its copies as well if the copies are "unchanged"
and therefore the `arch_updated` should not be set to `True` in such as case,
as the goal of this flag is to mark the view as `arch_updated` if it was updated by the user,
not from a data file loading.

Because the views are marked as `arch_updated`,
in 13.0, when updating the theme view "templates" (`theme.ir.ui.view`),
the copies are not being updated even if they have been left untouched:
https://github.com/odoo/odoo/blob/23511dffb9e3f597a7df9bb834d008f74abb07b8/addons/website_theme_install/models/ir_module_module.py#L165-L166

This is really problematic for upgrades, as the "copies" (the themes views) are not updated
according to the latest changes in the xml files, even if the views have been left untouched by the user.

For instance, this change in the common theme:
odoo/design-themes@29da153784705b48b8c6b99fcdaa5bcbce54f183
is never updated in databases, resulting in the below traceback
```
ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view

Fout context:
Weergave`s_badge_options`
[view_id: 2103, xml_id: n/b, model: n/b, parent_id: 901]

load could not load template
ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view
```

opw-2255753

closes odoo/odoo#51969

X-original-commit: 614214a08b7e19605228c96fbdef1a60752ba575
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Before this commit, url preview of a theme was theme_xx/static/yyy.png
Now we make this url absolue /theme_xx/static/yyy.png

It was the expected behavior, and since werkeug 15.0 utils.redirect() don't use
'/' anymore as root but the current path.

Without this fix, theme selector uses /web/image/<id>, and the location become
/web/image/theme_xx/static/yyy.png instead of /theme_xx/static/yyy.png

closes odoo/odoo#51018

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

During theme install, theme.ir.ui.view are copied as ir.ui.view for the
requested website.
During theme update, those already created ir.ui.view will receive the
theme.ir.ui.view modifications, including the `arch`, even if it was changed by
the user, meaning the user changes would be lost.

Here are some examples which will be wiped away when the theme
is updated (only if the view is loaded from the theme module):

- Changes made from website HTML/CSS/JS editor.
- Changes made from website builder e.g. Theme modify footer with XPath
  and user make changes in footer then user changes will be gone on theme update
- Changes made directly in the arch of ir.ui.view in the backend.

This commit fixes that behavior by not updating views which were modified by
the user.

closes odoo/odoo#49224

X-original-commit: 9906e1d403c4e9137a0313c342a455f425e95b8e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>

Themes image would not be shown correctly in the theme selection if the
`website` module was installed in CLI.
Indeed, the code supposed to load the theme images was done in the kanban view
during theme selection after installing module through apps screen.

Now, this code is encapsulated and called in post_init hook of website.
This was also needed for an improvement on `test_themes` module, see
https://github.com/odoo/design-themes/pull/195.

closes odoo/odoo#42206

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Before this commit, the website was given as a parameter of the
_post_copy function which is called after theme install. It was then
transfered through the context when calling the theme sub' post_copy
function.

It makes actually more sense to directly call the _post_copy function
with the right website in the context instead of a parameter. This will
also allow to call enable_view/disable_view in the default post_copy
common to all theme, with the right website.

closes odoo/odoo#41312

Signed-off-by: Romain Derie (rde) <rde@odoo.com>