If a theme post copy wants to enable/disable a view, this is to
enable/disable a given functionality which is disabled/enabled
by default. So if a post copy asks to enable/disable a view which
is already enabled/disabled, we would not consider it otherwise it
would COW the view for nothing.
closesodoo/odoo#28772
The goal of this commit is to handle 3 cases:
===============================================================================
- Correct loading of downstream themes for existing themes at (auto)install
eg. If we have `theme_A` loaded on a website and we install `website_sale`,
then `theme_A_sale` must also be loaded automatically on that website.
- Allow migration of every theme/website from the command line -u
When there is such an explicit upgrade, the Odoo framework was already
handling the upgrade of the modules, but it did not take care of reloading
the appropriate themes on the websites using them.
- Allow upgrade of only one theme from the interface
When using the UI to upgrade a theme, we want the user to be able to upgrade
only the current website and not any other. This will upgrade the modules
of all themes in the stream, but reload them only for the current website.
===============================================================================
- Move install/upgrade logic into the `write` method to automatically take
advantage of base features such as correct order of dependencies.
- Create methods to correctly compute the dependency stream of a theme:
upstream, downstream, and both ways.
Upstream: limited to modules with name starting with `theme_`.
Downstream: limited to modules with name starting with current theme name.
- Change `_update_records` method to better look for dependencies
- Change `button_choose_theme`:
- Always upgrade the stream before installing a new theme.
- Move `_convert_to_base_model` logic into `theme_models.py`
================================================================================
There are a lot of flows to take into account, some of which may be combined
with others.
- Dependencies such as website_sale or website_blog can be:
- already installed when loading a theme
- (auto)installed later when the theme is already in use
theme_A_sale and/or theme_A_blog has to be loaded on every website using
theme_A as soon as it is needed.
Not all themes have such dependencies.
- A theme can have other themes as dependency.
- The proper dependency chain must be taken into account when installing
or upgrading.
- Some themes do not have any dependency at all (theme_default, theme_bootswatch).
- Different websites can use the same theme.
- All of them have to be upgraded when using -u
- Only the current website must be upgraded when doing it from the UI
- Different websites can use different themes, including intermediary themes.
eg. - website1 may use theme_A
- website2 may use theme_B (depending on theme_A)
Moreover, theme_A and theme_B might have downstream themes such as
theme_A_sale and theme_B_sale (which depends on theme_A_sale).
In that case it is important when manipulating theme_B to also take into account
the relation it has with theme_A_sale even though theme_A_sale doesn't start
with the same name as theme_B and it is not in the direct stream of theme_B.
Authored by @seb-odoo with contributions from @dbh-odoo and @JKE-be
and precious help from @rde-odoo
PR: #27511closesodoo/odoo#27838
How to reproduce
* install website_theme_install;
* go on Apps -> Apply scheduled upgrades;
* Hit Cancel;
* there is a crash because somehow when writing on module self is a void
recordset and self.name is therefore False and cannot starts with 'theme';
This commit fixes that by ensuring self is not void before checking its
name.
Before this commit, it remove and reload the theme.
Now we try to make a real update of view except for active field
We cannot know if it is True into the template or if it is the default value.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
The method failed to enable views which were created by copying a
theme.ir.ui.view. This is because standard views were found with the
'ref' method while those particular ones were found thanks to the
copy_ids field... which only found the already active ones by default.
The priority was set to a low value while it was meant to be a high
value. Indeed, we want that if that template is active, the customize
modal is emptied no matter what, so it has to be called last.
This is to have an understandable behavior if our code fails to mark the
template as inactive on a theme installation. With this commit, the
customization dialog will be empty. Without this commit, it gives an
error which can lead to think we made a mistake writing the theme's own
customization dialog while it was in fact inheriting from an emptied
dialog.
Before this commit, we return an act_url, in this case the breadcrumb is not
build and the user cannot retruen to the settings in one click.
task-1878245
Before this commit, if you have some inactive views (option form customize e.g.)
the unload crash since you cannot remove views that is still referenced by
inherit_id. Now with search with inactive views to delete all.
* theme_bootswatch, theme_default
Before this commit, the customization dialog for themes was not
multi-website. That means if a theme was installed on a website, the
customization dialog was enabled for all the websites.
Note: this commit uses the '_post_copy' system of theme installations
for the first time and it had to be adapted a little bit.
Reorder res.config.settings for website
Make website_id in no create in most view
Revamp res.configsetting and view Form simplified
Transform old 'useless' stored field for presentation by computed field.
We can consider that if there are not key, feature is disable.
Co-authored-by: rde-odoo
Co-authored-by: jke-odoo
From now, when you install a theme, it load the data from xml to template
table theme [ir.ui.view|ir.attachment|website.page|website.menu].
Data are only copied from this template table into the real table when you
choose a theme on a website; Making them website_specific and with a link
to the original to allow futur update.
A special case is done to create theme.ir.ui.view when you are installing
a theme, even if you continue to use template tag to create quick view.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
qsm-odoo