Commit Graph
15 Commits
Author SHA1 Message Date
diagnoza f7b957f611 [FIX] website: ensure unicity of find
Before https://github.com/odoo/odoo/commit/254d40ffcc21f56a80a1814da7f6355d44e5670b it was possible that when a user cropped an image
using the crop tool, a copy of the original image was created that
had both original_id and theme_template_id carried over, therefore
find could be multi-record. We strengthen that search by adding
original_id=False, which ensures we always fetch the record of the
original image and not also its copies. In addition, databases that
happen to have this issue of corrupted data will be fixed
during an upgrade with https://github.com/odoo/upgrade/pull/3110.

closes odoo/odoo#82725

X-original-commit: e4bb0cd4466404e2fba62ae2d3bbaebd831fbcb2
Signed-off-by: Christophe Simonis <chs@odoo.com>
2022-01-13 17:23:58 +00:00
Martin Trigaux c7bac3dee0 [IMP] *: make ir.model.data helper private
No reason to interfact with them directly in RPC
2021-08-10 13:49:04 +02:00
8cc066173d [IMP] *: Improve assets management
This commit changes the way assets are declared in Odoo modules.

Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.

Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.

Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.

More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).

Task: 2352566

Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
2021-03-31 13:57:17 +02:00
Romain Derie 6a9b5bba9b [FIX] base, website: replicate inherit_id update on cow view
Before this commit, only whitelisted fields would be updated on cow views
during a module update.
A field would be whitelisted if he had the same value than the original view,
see it as a heuristic to not write on modified fields.

But `inherit_id` is not that simple, even if the cow view has a different value
than its original view, it doesn't mean it was modified by the user, it is just
because of the cow mechanism that assigned a copied view as inherit_id, which
is just a copy ofthe original one.

We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
the same.

In practice, it means that cow'd views did not receive the `inherit_id` updates
as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
where `portal.my_account_link` had its `inherit_id` changed from
`portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059:

Considering a module update changing `inherit_id` of D from A to B, the
following use cases are expected. Without this fix, D' never move:

CASE 1
  A    A'   B                      A    A'   B
  |    |                 =>                 / \
  D    D'                                  D   D'

CASE 2
  A    A'   B    B'               A    A'   B   B'
  |    |                 =>                 |   |
  D    D'                                   D   D'

CASE 3
    A    B                        A    B
   / \                   =>           / \
  D   D'                             D   D'

CASE 4
    A    B    B'                  A    B   B'
   / \                   =>            |   |
  D   D'                               D   D'

Opw: 2422773
Opw: 2422727
Opw: 2422770
Opw: 2423406
Opw: 2423859
X-original-commit: ff69f11e9c97d63d9319a8094a87af93984aba38
2021-02-12 15:52:37 +00:00
Benoit Socias ccfca271b9 [IMP] website: keep loader alive until editor is opened
Before this commit the navigation toolbar was accessible after selecting
a theme before the editor was opened, which on slow connections made it
possible for users to leave the screen and miss the tour

After this commit the loader animation of the theme installation is
blocking the access to the screen until the editor is opened thus
preventing user to navigate elsewhere before seeing the tour

task-2387608

closes odoo/odoo#62029

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
2020-11-26 09:28:14 +00:00
fw-bot c1e0b03d8b [IMP] website: make homepage tour, available on homepage only
Homepage tour starts with a very generic step 'drop snippet'
So, you can be in the middle of another tour and see the step of homepage tour.
This doesn't fix all cases, but make conflict less frequent.

E.g.

go to step 4 of tour event
click on save (before doing the step 5)
click on edit
Element is no more dirty (because save before step 5) so the step 5 not visible,
Tour with higher sequence (== lower priority) become visible. (e.g.: homepage)

Forward-Port of bca6cf2693d38c76b1af08398a3125bb16b59c15

closes odoo/odoo#61157

Related: odoo/design-themes#416
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
2020-11-04 09:54:08 +00:00
Jeremy Kersten 5c0d64cb17 [IMP] website: redirect in edit mode after theme selection
This commit redirect the user to the website in the edit mode once a theme has
been selected.

task-2172208

X-original-commit: f474eac4543712ae5b1c7d614f9eff9367445107
2020-09-11 16:31:50 +00:00
qsm-odoo f7ff02b0fb [FIX] website_theme_install: properly reset config on theme change
Before this commit, some code was resetting some default website config
on theme change.

Problem 1:
This was not done when *removing* a theme. Thus when you wanted to go
back to a default website theme, you were not properly reset to the
default theme config. This could actually crash: some themes define
more fonts than others; so if you selected font 13 in one theme then
removed the theme, the default one would crash if not properly reset
as font 13 would not exist.

Problem 2:
It was done for every theme dependency, making theme change slower for
no reason.

Problem 3 (theorically, not tested):
The current code worked by chance as it called the website
'make_scss_customization' method without giving any website to it. It
actually worked by fallback on the right website in normal user cases
(user in the context of installing a theme on a specific website) but
may not be working when trying to install a theme on a different website
calling those functions from custom code.

Now, a dedicated method is there for config reset and is called at the
correct place with the right website in the context.

closes odoo/odoo#53743

X-original-commit: 7307d696449ea2b7a231b0b9087e64f6bbf65d26
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
2020-06-26 14:00:44 +00:00
Denis Ledoux 7b8d12e6dc "[REVERT] website_theme_install: do not mark theme views as arch_updated when loaded from data files"
This reverts commit fdd4a143f2148ec5f4aeea80fecd3138fea95dc6.

See discussion in #51969

closes odoo/odoo#52028

X-original-commit: 0e602cc0ac295621864b50509f78bd5de1e61718
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
2020-05-27 19:59:30 +00:00
Denis Ledoux 4fc0f2c042 [FIX] website_theme_install: do not mark theme views as arch_updated when loaded from data files
A view is marked as `arch_updated` if `arch` is being written on it
and `install_filename` is not in the context:
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/odoo/addons/base/models/ir_ui_view.py#L460-L461

When a view is being updated from a `theme.ir.ui.view` through `_update_records`
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L29
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L92
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L208
https://github.com/odoo/odoo/blob/7b1a6c00663239fbbab3d8ea5028e0825f4eb0dd/addons/website_theme_install/models/ir_module_module.py#L168

we can basically consider it comes from a data file,
the template is updated, and its copies as well if the copies are "unchanged"
and therefore the `arch_updated` should not be set to `True` in such as case,
as the goal of this flag is to mark the view as `arch_updated` if it was updated by the user,
not from a data file loading.

Because the views are marked as `arch_updated`,
in 13.0, when updating the theme view "templates" (`theme.ir.ui.view`),
the copies are not being updated even if they have been left untouched:
https://github.com/odoo/odoo/blob/23511dffb9e3f597a7df9bb834d008f74abb07b8/addons/website_theme_install/models/ir_module_module.py#L165-L166

This is really problematic for upgrades, as the "copies" (the themes views) are not updated
according to the latest changes in the xml files, even if the views have been left untouched by the user.

For instance, this change in the common theme:
odoo/design-themes@29da153784
is never updated in databases, resulting in the below traceback
```
ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view

Fout context:
Weergave`s_badge_options`
[view_id: 2103, xml_id: n/b, model: n/b, parent_id: 901]

load could not load template
ValueError: Element '<xpath expr="//div[@data-js='content']">' cannot be located in parent view
```

opw-2255753

closes odoo/odoo#51969

X-original-commit: 614214a08b7e19605228c96fbdef1a60752ba575
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
2020-05-27 10:42:06 +00:00
Jeremy Kersten 3e4b6f939d [FIX] website: use absolute url for theme image
Before this commit, url preview of a theme was theme_xx/static/yyy.png
Now we make this url absolue /theme_xx/static/yyy.png

It was the expected behavior, and since werkeug 15.0 utils.redirect() don't use
'/' anymore as root but the current path.

Without this fix, theme selector uses /web/image/<id>, and the location become
/web/image/theme_xx/static/yyy.png instead of /theme_xx/static/yyy.png

closes odoo/odoo#51018

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
2020-05-11 13:04:39 +00:00
Romain DerieandKishan Gajjar babbe363b6 [FIX] website_theme_install: do not write view arch if it was modified
During theme install, theme.ir.ui.view are copied as ir.ui.view for the
requested website.
During theme update, those already created ir.ui.view will receive the
theme.ir.ui.view modifications, including the `arch`, even if it was changed by
the user, meaning the user changes would be lost.

Here are some examples which will be wiped away when the theme
is updated (only if the view is loaded from the theme module):

- Changes made from website HTML/CSS/JS editor.
- Changes made from website builder e.g. Theme modify footer with XPath
  and user make changes in footer then user changes will be gone on theme update
- Changes made directly in the arch of ir.ui.view in the backend.

This commit fixes that behavior by not updating views which were modified by
the user.

closes odoo/odoo#49224

X-original-commit: 9906e1d403c4e9137a0313c342a455f425e95b8e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>
2020-04-08 12:15:25 +00:00
Romain Derie c86bff6a02 [IMP] website: load theme images also when module install through CLI
Themes image would not be shown correctly in the theme selection if the
`website` module was installed in CLI.
Indeed, the code supposed to load the theme images was done in the kanban view
during theme selection after installing module through apps screen.

Now, this code is encapsulated and called in post_init hook of website.
This was also needed for an improvement on `test_themes` module, see
https://github.com/odoo/design-themes/pull/195.

closes odoo/odoo#42206

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
2020-01-07 16:11:52 +00:00
qsm-odoo 322d5768a7 [REF] website: call _post_copy with website in the context directly
Before this commit, the website was given as a parameter of the
_post_copy function which is called after theme install. It was then
transfered through the context when calling the theme sub' post_copy
function.

It makes actually more sense to directly call the _post_copy function
with the right website in the context instead of a parameter. This will
also allow to call enable_view/disable_view in the default post_copy
common to all theme, with the right website.

closes odoo/odoo#41312

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
2019-12-05 16:32:39 +00:00
qsm-odoo 88e910e187 [REF] website, *: merge website_theme_install into website
* theme_bootswatch, theme_default, website_theme_install
2019-11-12 15:53:13 +00:00