This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
* theme_bootswatch, theme_default, website_theme_install
This commit makes use of the new 'auto' widget for font selection:
instead of enabling a template which will enable a scss file which sets
a font variable to a specific value... we directly allow to do a scss
custo which sets that value.
The code in charge of resetting font customizations on theme switching
is also moved and refactored here in website (instead of being specific
to each theme).
Part of https://github.com/odoo/odoo/pull/33442
task-1974659
Co-authored-by: qsm-odoo <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 #1909865closesodoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
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.
closesodoo/odoo#31662
Signed-off-by: Jérémy Kersten (jke) <jke@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
closesodoo/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
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
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.