Before this commit, there were multiple issues related to the creation
of `theme.website.menu` records in a theme:
- Not possible to add a menu in the existing website's navbar
- When one would try to create a `theme.website.menu` that menu would be
created for every website when instaling the theme on a particular
website, which is terribly wrong as it goes against the multi-website
holy grail rule: when editing a website, do not impact other websites.
- Not possible to create a mega menu
Now, one can create a menu:
- as a navbar top menu
- as a child menu of another theme menu
- as a whole new menu hierarchy (top level container)
This is not possible to create a menu as a child of a website.menu, like
adding 2 submenu to the existing contact us menu.
First, this is technically impossible to do without introducing yet
another hack code in the `website.menu` write. Indeed, there is no way
to identify a generic menu's website copies. Neither through a direct
DB field, neither through a persistent info like we do with the `key`
attribute of views. So there is no reliable way to tell the system to
add a menu below the "Contact Us" menu of the website, as this is just a
menu copied when the website was created. We could obviously later add
a `key` field or something like that to identify an XML menu's copies.
Second, there is a workaround as one has to recreate the website.menu
and delete the original one (through a `<function/>` record).
Third, this should not be the main use case about menu creation in
themes.
----------
Some fields were also missing regarding the `website.page` model.
----------
A stable attempt is done at [1], this is where the current commit
originates from.
As the Odoo 17 release is quickly approaching, it was decided to first
write the proper IMP in master from which we will see what can be
backported and how, if needed.
[1]: https://github.com/odoo/odoo/pull/86669
Part-of: odoo/odoo#99099
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Currently, "Editor and Designer" can't edit the views which originate
from a theme (which are copies from the theme `theme.ir.ui.view`
records).
This error is caused by [1], which is preventing the `arch_updated`
field to be set to `True`, as this field is supposed to be set to `True`
only on manual user change, not during module update.
Indeed, restricted users don't have access to the themes records, making
the overide raising an error.
But there were actually no reason for this code to be executed outside
module operation.
Steps to reproduce:
- Create any view in a theme module.
For example: create a custom footer view.
- As a "Editor and Designer" user, edit this view through the website
builder.
- An access right error is raised.
[1]: https://github.com/odoo/odoo/commit/1eb7c577ecb31c2f0876b6dd76769e2b47802cb0closesodoo/odoo#91255
X-original-commit: d2be8dc99eb99321be1172af447d5f2536c17364
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some theme are enabling an header template. When doing so, they also disable
the default header template.
But this is not enough, as the user could have changed that template and it is
not the default one anymore.
Then, updating that theme (UX, CLI, Migration) will raise a traceback.
Step to reproduce:
- Create a website and install theme avantgarde
- Enter edit mode and select Magazine header template
At that point, update the theme, either:
- Through the UI, on theme switch screen, click on Update
- Through CLI, just run a `-u theme_avantgarde`
-> A traceback will be raised about an xpath error, as both the magazine header
template and the hamburger header template are active at the same time. Only
one template is supposed to be activated.
The issue also impact migration, as migrated website can't be accessed due to
the xpath error on rendering.
Theme being impacted (at least): Avantgarde, Graphene & Nano
Note that when installing one of those themes for the first time on a website,
the error won't occur as `_reset_default_config()` will be called through
`_theme_remove()`.
Note that this fix will ensure the correct template is set (and all others are
disabled), but the scss variable won't be correctly set (as it would be if that
template change was done through the right panel).
This is not that much of a problem (considering what it solves), any later
change from the user through the right panel will solve that mismatch.
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
X-original-commit: f18cd32a936829d8a059db0d259189503ee5317f
Part-of: odoo/odoo#81953
Before this commit, the "ripple effect" no longer worked because the
assets were never activated for the following reason:
- To activate the ripple effect assets via the editor options, we
activated a template that no longer exists (with
data-customize-website-views). Instead of activating the assets with the
new system of assets using records.
After this commit, a new "data-customize-website-assets" xml attribute
was created so that the assets can enable/disable in the same way as the
views. The "write" method for ir.asset has also been overridden in
website so that each website has its specific assets (via COW).
task-2686370
closesodoo/odoo#81833
X-original-commit: 9f56357cc1f4a7b8606ef4d5fd431fc396bdf1e8
Related: odoo/design-themes#546
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Some themes replace the website.template_header_default template in the
website layout. This poses a problem when changing to another theme
afterwards because of the interaction between the website templates and
the _reset_default_config method:
1) Since version 15.0 the nav tag inside the header templates was
abstracted into a separate template (website.navbar) and added to each
header layout through t-call.
2) The _reset_default_config deactivates or reactivates views that were
enabled or disabled by the currently active theme. However, when doing
so, the default header is activated before the custom header is
deactivated.
As a consequence, after toggling the default header, there are
temporarily two header extensions in the website.layout template. They
both replace the //header//nav element. Because of the abstraction of
the nav element into a separate template by the header extensions, only
the first replacement will work.
task-2662497
closesodoo/odoo#77917
X-original-commit: b83a2110fd3035cc8466c4fa74f6530be5d00597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
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>
*: web_editor
All theme specific color palettes have been moved into website.
It allows to access them without having to install theme modules and
this is a preparation for our website configuration screen task.
Lists of palettes have been replaced by maps with palette names as keys.
Those names are composed of the palette's original theme name ('generic'
or 'base' for palettes not specific to a theme) and of an index
(ex: 'anelusia-2'), for compatibility.
To keep compatibility with previous version we also convert old color
palettes number to color palette name, specifically for each theme.
A side effect of this change is that we got rid of all gray palettes
which existed in some themes. Those were not fitting the new possibility
of gray customization in the third panel and were not always really a
good customization of the default grays (they still were there mainly
for historical purposes). Unfortunately, this may have some side effect
for old websites which used those grays but the new gray palettes (left
to the default one) should most of the time come as an improvement of
the old ones, and they are now customizable by the user. In the future,
we may associate a perfectly-chosen default gray palette, fitting the
customization system, for each color palette.
PR: https://github.com/odoo/odoo/pull/67488
task-2451965
closesodoo/odoo#67488
Related: odoo/design-themes#455
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Themes define records which are used as templates for the creation of
base model records on theme installation on a website.
E.g. a "theme.ir.attachment" record's purpose is to be a template for an
"ir.attachment" record creation on theme installation on a website.
Those final records have extra fields to indicate from which theme
template they come from. If those records are ever to be duplicated,
they should not duplicate those links to the theme templates otherwise
it may cause issues when uninstalling/updating a theme (you want the
records linked to the theme to be deleted/updated but not the duplicated
ones, which do not act differently from user created ones).
Duplicate ones will be linked to the website anyway (just like "normal"
user created ones) and should only be automatically removed if that
website is deleted.
The issue is more visible from 14.0 where applying some modifications to
images via the editor (crop / filter / optimization / ...) will
duplicate the original image before modifying it.
closesodoo/odoo#63951
X-original-commit: 890935bbdf924b06b7dabd89802f6dd824159a4b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
*: website_sale, website_sale_wishlist
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 77d82cfbddb64cc7302672c7741eb65c9fc4a125
*: portal, website_sale, website_sale_wishlist
Portal-without-website header is now more basic, without the need of
a collapsed element. It is then entirely replaced when website is
installed with header templates, t-calling all the main parts.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: d3d5983e0a76eb6500e0d3f78f128879b50390e0
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: web, web_editor
Instead of three lists + one map to define font information and user
choices saved as the index of the related fonts in those lists, the
fonts are now stored in an unique map <font-name> -> <data> and the
user choices are saved as the font name. This allow to have a visually
better definition of the fonts and allows to reorder fonts in the UI
without losing user customization (and actually simplify some code).
Unfortunately any user font customization < 14.0 will be lost, but this
is a small price to pay (users can still rechoose the same font in the
editor UI where they will go anyway to discover all the new shiny
features we are introducing there).
Part of https://github.com/odoo/odoo/pull/54065
task-2291398
closesodoo/odoo#54065
Related: odoo/design-themes#269
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a theme was chosen, the footer disappeared if any footer template
different from the default one was previously selected. The related
code is actually meant to revert back to the default footer template
when switching theme (allowing the theme to set a different default one
if it chooses to), but it forgot to enable that default one... and was
only disabling all non-default footer templates.
closesodoo/odoo#53762
X-original-commit: 9f5c630768cbcf56aec97ba4296f90f3d7fbfa5b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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.
closesodoo/odoo#53743
X-original-commit: 7307d696449ea2b7a231b0b9087e64f6bbf65d26
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Note: on color palette change, all the colors of the user are reset and
he is warned about it.
Part of https://github.com/odoo/odoo/pull/52224
task-2197038
When a theme module is updated the changes made on a view are considered
as user changes, prenventing the view from being updated in the future.
Fixed by comparing the arch being written with the arch of the original
view. If it is the same the record should not be noupdate.
Plus added a test to make sure the theme views receive theme updates
after being updated once.
Introduced by: https://github.com/odoo/odoo/commit/4acf177b4c55f3a16362cbeafea3d332ef4fe819closesodoo/odoo#51557
X-original-commit: 221470ab9c9eda3f3a4e2da0fa1a7bb23d6288cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Also remove all t-fields from footers to have only static contents in
footers. For social links, a controller is added so that a "static url"
/website/social/xxx always redirect to the correct set URL for the given
xxx social network.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
Co-authored-by: qsm-odoo <qsm@odoo.com>
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.
closesodoo/odoo#41312
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Romain Derie