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.
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.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
On website/theme installation and other website_* module installation,
an action was triggered to launch tours. These tours are now used only
for tests and should not be used as onboarding anymore.
Note: in master these tours will be removed to use the new test system.
In new api, the context in encapsulated and propagated with 'env'. There is no need to add in the signature. Method decorated with api.multi/api.model replace method(self, cr, uid, context).
The module did only work in english because the themes were found
amongst the applications thanks to their categorie names.
Solution is to search categories thanks to their xml_id :
base.module_category_theme or base.module_category_theme_...
and not
base.module_category_hidden or base.module_category_theme_hidden
Nimesh Jethva