| Age | Commit message (Collapse) | Author |
|---|
|
* theme_bootswatch, theme_default, website_theme_install
|
|
Group the upgrade of upstream dependencies with the installation of a
new theme into a single install/upgrade operation. This fixes cache
misses occurring when accessing the state of a module after having
upgraded other modules.
closes odoo/odoo#38331
X-original-commit: 03b796b9e92e6eeeee877beaea133bdb6de0c6a3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
|
|
When a theme declares a view (a 'theme.ir.ui.view') with an inherit_id,
on installation, a view (a 'ir.ui.view') will be created with the
corresponding inherit_id. The problem is that this inherit_id may
reference a view that has been cow'ed at some point and thus the new
theme view will be attached to the non specific view by mistake.
Part of https://github.com/odoo/odoo/pull/37142
closes odoo/odoo#37750
X-original-commit: https://github.com/odoo/odoo/commit/f30b4dfdb90515bc54e691302f894184c9b1c55b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
|
|
*: theme_bootswatch, theme_default
Before this commit, the first time a website was loading a theme, it would
not be redirected to the frontend afterward (even if that theme was already
installed on another website).
Any other theme installation on that website would redirect to frontend as it
should.
Indeed, the first time it would use the `act_url` returned by `next()` which
would only be called during the first time installation on the website.
All the `ir.action.todo` related to themes can be removed anyway, as you can't
install directly a theme. It can only be installed through website settings >
load a theme.
In which case we will always want to redirect to frontend.
task-2070463
closes odoo/odoo#37306
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
closes odoo/odoo#37569
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
|
|
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865
closes odoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
|
|
|
|
Before this commit we only remove upstream but not itself.
|
|
+ remove duplicated arch
|
|
Allow to set mode=primary on new view for theme
|
|
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.
|
|
The categories other extra rigths and hidden are not used now.
|
|
Useless since 5238595648c986650e7ed8878462afd159d62b42
|
|
Commit a00ea2755d93cef160a13d4652729e3c655fdbb8 restored correct
definition of external id for the theme/hidden category but forgot
to adapt its use everywhere.
|
|
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
|
|
New module to propose theme installation on website installation.
|
