| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Commit 5a81d8883 fixed the COW view deletion on module update but introduced an
error when installing a theme.
Indeed, when installing a theme, the first step is to remove the currently
installed theme from the website (by unlinking its ir.ui.view).
Commit 5a81d8883 introduced the fact that deleting an ir.ui.view during a
module uninstall also search and delete the COW views, calling
`_get_specific_views` (that expects a singleton).
When installing a theme, it calls `_theme_cleanup` which search COW views and
unlink them. If not cow view, unlink is called with an empty record set raising
the singleton error.
closes odoo/odoo#31662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
task-1907934
closes odoo/odoo#31114
|
|
|
|
|
|
Inspired by l10n_multilang
When a theme is installed, the theme.* records are used to generate actual records.
The same was as we use account.account.template to create account.account, the
translations of the theme records should be propagated to the new records.
opw-1918120
closes odoo/odoo#29748
|
|
|
|
|
|
* website_theme_install
This commit will add MODULE_UNINSTALL_FLAG to the cleanup methods of themes and
modules.
This is necessary to also unlink inherited views of those we try to unlink.
Before this commit, an error would be raised when trying to delete a view that
still had other inherited views (either created manually by the user, or with
just bad luck in the order of which the views are deleted).
PR: #29753
|
|
This comment is not true, we originally wanted to code it this way but we changed
our mind and forgot to remove the comment.
PR: #29753
|
|
|
|
|
|
closes odoo/odoo#30045
|
|
|
|
|
|
In a particular case, `_views_get` was mixing apples and oranges, ir.ui.view
and theme.ir.ui.view.
This was the case if a theme has a theme.ir.ui.view t-calling another
theme.ir.ui.view.
(Only theme's sale bridge cause this issue, eg theme_kea_sale.products)
Then, having that theme installed on a website would make all other website
without that theme to crash when opening the /shop customize menu.
Indeed, the theme.ir.ui.view would have the xml_id theme_kea_sale.search.
The generic view `website_sale.products` would have `theme_kea_sale.products`
as inherit child which is website specific and t-call `theme_kea_sale.search`.
Then, on a website witout theme_kea installed, opening the customize menu would
call `get_related_views` that would call `_views_get` that would loop through
inherit children calling `_view_obj` that would not find a view with that key
and would fallback on self.env.ref, finding the theme.ir.ui.view.
Note: `_views_get` might return specific view for another website but that will
be filtered on `get_related_views` override in website.
Step to reproduce:
- Have at least 2 websites and website_sale installed
- Install theme_kea on a website, it will also install theme_kea_sale
- Go on the website that has not theme_kea installed
- Go to /shop
- Open Customize menu, it won't load because of python crash
opw-1914576
Closes #29347
|
|
|
|
Update to reflect the recent code changes
closes odoo/odoo#29636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
closes odoo/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: #27511
closes odoo/odoo#27838
|
|
|
|
It should be model_terms:
Fixes odoo/docker#219
closes odoo/odoo#27664
|
|
|
|
|
|
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.
|
|
|
|
Active field was ignored in all case instead of just update
Button 'update theme' call wrong function
|
|
|
|
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.
|
|
|
|
To match new model_terms syntax
|
|
|
|
|
|
Before this commit, you had 'choose a theme' into the form view.
It should be only visible in modal
task-1878245
|
