Since [1] it is possible to request that some blocks are not displayed
on mobile devices.
This commit adds a similar option to prevent blocks from being displayed
on desktops (i.e. on non-mobile devices).
[1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0
task-2900730
closesodoo/odoo#101483
X-original-commit: 3103e0553011b5c1f4078972d7a88fa3fd4068b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Antoine (anso) <anso@odoo.com>
The goal of this commit is to add a 'Publish' / 'Unpublish' button to
the additional actions of the 'website content' list views.
'Archive' / 'Unarchive' options are also removed for the 'website.page'
records.
task-2889981
X-original-commit: de02335b8db1396a24e10b78f8f78ed79fded421
Part-of: odoo/odoo#101215
*: website_blog
The goal of this commit is to update JS code to have the same behaviour
from the 'website content' list view (trigger the 'new content' dialogs
on "CREATE", add a website selector to filter content) on kanban views
too.
The blog post kanban view has been adapted to use this. Other "website
content" related records will receive a kanban view in a further update.
This is is also important so that the mobile UX is nicer.
task-2889981
X-original-commit: ed09db19c372da8d8be541f365117d1ce8e965ba
Part-of: odoo/odoo#101215
The 'addPage' code on website pages list view was duplicated from
'new_content.js'. The goal of this commit is to move this code to the
'AddPageDialog' component.
task-2889981
X-original-commit: 58698f848703395ff680bc7586ecc8eec4fb61ae
Part-of: odoo/odoo#101215
The goal of this commit is to:
- Tweak the website filter (on website pages list added at [1]) to make
it work for all website content records (page, blog, ...).
- Update the 'New Page' dialog to be able to select the website_id for
the new page.
- Tweak the '_compute_is_homepage()' method to set 'is_homepage = True'
on website's '/' page when 'homepage_url' is not set in settings.
[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
task-2889981
X-original-commit: d6014c60acc4231a5e56d492d2a39deaf789cbe8
Part-of: odoo/odoo#101215
This commit make it possible for design theme tours to define
preconditions based on the CSS variables in order to make sure that
the tour is run within a website that has the specific theme applied.
See https://github.com/odoo/design-themes/pull/590.
task-2687506
closesodoo/odoo#101119
X-original-commit: b29e17765f4e912b2dd472493b5be500b3a32c87
Related: odoo/design-themes#594
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To allow increasing page loading performance, websites can now choose to
use system fonts instead of using a google font. It is also the default
in the default theme of Odoo from now on. The option will automatically
be available for all themes whatever way they defined their available
fonts but will only be used as default if explicitly asked by the theme
(as done in the default theme).
task-2993054
X-original-commit: c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
Part-of: odoo/odoo#101068
Before this commit, if a theme wanted to define a main font for their
theme and let the "headings", "navbar" and "buttons" ones use the same
they had to add this in their map:
```
'font': XXX,
'headings-font': null,
'navbar-font': null,
'button-font': null,
```
Indeed, without setting the "null" values, those font would use YYY
which is the first font defined in the theme config, which might be
different from XXX. And if forcing XXX 4 times, like most themes do at
the moment, if the user wanted to change them all, he had to change the
4 ones instead of the main one.
Now, only the 'font' value use the first font defined in the theme
config if not explicitly set. So forcing the null values is not
necessary, it will be the default behavior.
The advantage is thus also functional, as most theme forced all their 4
fonts so changing the main one did not change the others.
task-2993054
X-original-commit: c6b56955f62c6b837b477223daac2d87ab984efb
Part-of: odoo/odoo#101068
Before this commit, if a theme defined in its website values "palette"
"null" as value for the "headings-font" variable, it was properly making
the headings font use the default "body" font as expected but the editor
panel showed an empty value instead of displaying the "body" font value.
Now, that panel UI problem is fixed for the headings, navbar and buttons
fonts. Note that all our current themes force the font for each of those
component so the bug was never visible anyway. That's why it is merged
here in 16.0 and not before but it could be backported if necessary
(although it is only an UI bug which is not really confusing).
Before this commit, for a theme which says "use XXX as main font" and
"let headings follow the main font", the UI displayed:
Main font: XXX
Headings font: /
After this commit, it displays:
Main font: XXX
Headings: XXX
task-2993054
X-original-commit: b07a408f2f80638a2abdda8304e31d3dac9968b3
Part-of: odoo/odoo#101068
What is done in start should be undone in the destroy.
closesodoo/odoo#100904
X-original-commit: a221342ca18db892153bbf4139c0bee7cd1e9bde
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the merge of Bootstrap 5, some data attributes was non converted
to the new syntax for Bootstrap 5 (data-interval -> data-bs-interval).
closesodoo/odoo#100935
X-original-commit: bb9f7542b9dd481c363b593aa97d4a6f2d5ecd1f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit transfers responsive related customizations for
ControlPanel, SearchView and SearchPanel to community which allows them
to render properly on smaller devices.
Note: a page reload (aka. F5) is required to properly adapt the UI after
a resize to a mobile-like size.
X-original-commit: 26a755610da36b01ba07ca224cc5937a672eb6a8
Part-of: odoo/odoo#100759
Since _checkScrollbar, _setScrollbar and _resetScrollbar doesn't exist
anymore in BS5 and that these functions were removed during the
migration as you can see here: [1], compensateScrollbar is no longer
used for modals. That's why this commit removes the
'compensateScrollbar' function from 'jquery.js' and adds the code of
this function in the 'menu.js' file in Website because that's the only
place we need it now for the affixed header.
[1]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7#
task-2985702
closesodoo/odoo#100894
X-original-commit: f3f45c93d3e942b224332924d66f2e48fc711002
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This reverts commit https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2.
This commit was added to no longer have to compensate the scrollbar
width to display the fixed header. To do this, this commit had changed
the 'fixed' CSS position of the affixed header to 'sticky'. But this
introduced several issues with header effects (the main problem with the
"sticky" position is that Chrome and Firefox don't handle it in exactly
the same way.). For his reasons, we decided to revert the commit and get
back to a situation where everything works correctly.
task-2985702
X-original-commit: ab9a4497c9ade5d91d7661bb3a4f47a683be1c32
Part-of: odoo/odoo#100894
Since [1], as part of the new translation system made with [2], saving
multiple elements in a website page was only saving the first one. E.g.
- Enter edit mode of your homepage
- Add something in the main area of the page
- Add something in the footer
- Save
=> Only the main area is saved, not the footer.
This was actually the same in translate mode... only translation of the
first edited area could be saved.
At least, with the bug fixed version of [1] comes the small advantage
of not saving multiple times the same field (except for view parts).
E.g.: an event's dates are displayed multiple times in different formats
-> in 15.0, 3 RPC were made by date changed, now only one is made.
[1]: https://github.com/odoo/odoo/commit/1b473cf0db4d85c2b523ac87fbab533bce5f3e21
[2]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224closesodoo/odoo#100762
X-original-commit: c834d151afed0ca633ffb6bcba2f45b544689e74
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The mini UI on the frontend as a connected backend user was a bit
confusing: the "Edit" button used the exact same design and wording as
the "Edit" button in the backend but it had not the same effect as it
did not enter edit mode but just redirected the user to the website
preview (client action iframe).
We still want the same behavior, we just needed another button design:
- Change the label from "Edit" to "Editor".
- Change the "pencil" fa icon with the website app icon (same as app
switcher in enterprise).
- Use a dark color instead of the primary color. This reuses a dark
color of the website edit mode.
closesodoo/odoo#100355
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
With [1] moving the website in backend, it is now possible to display
a backend discuss chat window while browsing your website.
This window is unfortunately hidden behind the SnippetEditor when it is
open.
The choice was made to hide the chat window when the edit mode is
activated, as it could hide some content of the page.
Steps to reproduce:
- Open a Discuss chat window using the systray item from the app grid
- Open website
- Click on Edit
Chat window is hidden.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#100098
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website service method fetchWebsites was not
clearly defined: it was fetching the user groups, the websites, the
current website and it was also setting the service's current website.
There is a difference between the get_current_website backend method and
the getter from the website service, introduced in [1]: the
websiteService.currentWebsite value referes to the website currently
edited in the WebsitePreview client action. From that value depend other
components visibility (like the contextual menus).
So when a fetchWebsites call was done from outside the client action,
from a PageListController with [2], it was breaking the flow by setting
a currentWebsite outside the client action and it could lead to bugged
flows:
- Go to the "Pages" list view
=> The contextual "This page" menu is not shown, it's correct
- Refresh the page
=> The "This Page" menu is shown (and broken).
To fix that, the fetchWebsites method is divided into a fetchUserGroups,
the searchRead on the websites, and another call to get_current_website,
located in the client action. It allows to load the client action iframe
with the last viewed/edited website.
Also, the menu "This Page" is shown only when there is a pageDocument at
the website service level.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
task-2687506
closesodoo/odoo#100055
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit, we simply set 'position' to 'sticky' on 'o_header_affixed'
to avoid to manage it's position with 'padding-top' and 'right'.
- 'padding-top' css property was used to compensate the navbar height
at the moment where the stacking context change because of the
fixed position.
- 'right' css property was used to prevent the menu to overlapp
the scroll bar.
Part-of: odoo/odoo#99338
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
In this commit two errors in the rendering of the mega menu are fixed:
* the position of the mega menu when the option `Sub Menus` is `On Hover`
this bug is due that we show the mega menu manually adding the `show`
class on the element in our code. However, in the `On Click` mode,
it's Bootstrap's javascript that handle the show/hide state.
Bootstrap adds the `show` class and also adds the attribute
`data-bs-popper="none"` to the element. In `On Hover` mode this
attribute was missing.
* the render of mega menu in the `+ icon` (`o_extra_menu_items`).
This error occurs because in Bootstrap 5 the width is set with the
`width` property and in Boostrap 4 it was `max-width`. In Odoo
`col-XX-YY` CSS rules are overridden when the mega menu is in the
`+ icon`, but the `max-width` was not changed by `width` during the
Bootstrap 5 migration.
closesodoo/odoo#100068
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Ensure all the `#top_menu` links are unremovable.
This prevent the editor to merge two `<a>` elements together
during delete commands.
task-2967314
closesodoo/odoo#99966
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: web_editor, website_blog
This commit improves the mobile preview of websites. A mobile phone
image has been added around the iframe during the mobile preview. This
image was already used for the themes mobile preview, this is why the
css code has been unified to be used in these 2 mobile previews.
Parallel to this commit, we have modified the websites displayed in the
iframe of the preview of the themes so that the scrollbar of these is
visible (before it was hidden behind the image of the phone) but with a
smaller width in mobile mode.
This commit also improves the button to switch to mobile preview by
coloring it green when mobile preview is active.
task-2890050
closesodoo/odoo#98061
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event, website_links
This commit fixes the navbar on the enterprise mobile mode. With the
enterprise modules, in mobile mode, the navbar menus are removed and
displayed in an an additional systray item, the BurgerMenu.
This behavior was not adapted to the website systray and contextual
custom menus, introduced in [1].
For the website systray, some elements are hidden in mobile:
- the "edit" and "translate" buttons,
- the mobile preview,
- the "+ new" new content button,
The logic for displaying the contextual custom menus is moved from the
navbar patch to a service, so that we can define a patch for the
BurgerMenu that uses that logic and has the same behavior as the
navbar.
For now, the "Menu Editor" and the "HTML/CSS Editor" menus are hidden in
mobile.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#99605
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit improve the design and simplify the implementation.
Popovers have been removed and the overall integration with boostrap is
increased allowing customization with the default boostrap variables.
Variables for (multi-)range input have been exposed at "theme-level"
allowing to customize these components when creating a new theme.
task-2907955
Part-of: odoo/odoo#98558
- adapt the html field and mass_mailing_widget to be owl components
- adapt the mass mailing view to be an owl view
task-2898432
closesodoo/odoo#94875
Related: odoo/enterprise#30915
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This was introduced alongside the introduction of the cookies bar in
odoo with [1].
It's not something we wanted but for some internal reason, we were not
allowed to introduce the cookies bar on the website without that warning
when enabling the settings (which also comes with Cancel button as
primary button..).
The compromise was accepted as having a cookies bar was something we
really needed.
It has now been accepted to get rid of it.
While some internal people still think we should educate people about
GDPR and cookies law, I doubt that this settings was the right place to
do it.
Indeed, it was more leading to bad UX as most people just clicked on
"activate anyway" without realizing they still had to save the settings
afterward.
[1]: https://github.com/odoo/odoo/commit/3028e9a8649ae5d9b23a1bdb989b903645ede5feclosesodoo/odoo#99917
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the button must be rendered when its text changes, the variable
that holds its text must be stored in the component state. The button
already had the right text before a bit by chance because the new name
was computed before the component was rendered. Now we make sure that
the component will be rendered when the name is recomputed. The problem
is visible if we slow down the getUserModelName function and go to a
forum.post from a forum.forum.
task-2889929
closesodoo/odoo#99599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit changes the indentation of the redirect_field template to be
more in line with the rest of the template in the website module.
closesodoo/odoo#99150
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit will adapt ThemePreview views to OWL.
Those views use custom components to achieve the desired layout and
functionality.
Part-of: odoo/odoo#99150
Co-authored-by: Younn Olivier <yol@odoo.com>
It is not common, but we sometimes need to modify translation components
in place. The goal is to have a mechanism to change translation
components and all future/present instances
closesodoo/odoo#99719
X-original-commit: 87f98e6bb82cb2319d7f923b838085befd823f72
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website_event, website_sale
The "Site" menu will now be organized in 3 sub-areas, the last two being
named "Content" and "This page". The first area contains a link to the
website iframe and the menu editor. The "Content" area will contain
menus to list all contents of the website (page, products, events, ...).
This commit only moves the "page" one, the others will be created by
other commits of this PR. The "This page" area contains elements
specific to the page (html editor, page properties, ...).
task-2889981
Part-of: odoo/odoo#98937
After [1], the frontend website page manager was replaced by a custom
'website.page' list view and, with following commits on this PR, this
view will be used with other website content models records (blog,
event, forum, ...) too.
The goal of this commit is to adapt the pages list code to the new Owl
view system.
Other changes (related to the view's behavior) were added in this
commit:
- "Page list action buttons" are removed, we keep only the action that
triggers the form view of 'page.view_id' in debug mode. Page properties
and SEO dialog can be accessed via the website iframe after clicking on
the page entry in the list. The clone button should be later restored as
part of the main website backend menu, still when viewing the iframe.
Meanwhile, it is accessible in page properties. The 'delete' button is
still accessible via page properties too but the standard "delete"
button when selecting records in the list view will later be improved to
act the same way.
- The "website switcher" on top of the list view (to filter records
which impact one website, generic + specific records) is added as part
of the search view. Limitation: it will only be shown for pages at the
moment.
- A standard "Create" button is added and displays the form view dialog
to create a new content record as with "+ New". Known bug: it only
allows to create on the first website at the moment.
- The click on page/content record should redirect to the corresponding
url/website_url in iframe. This is now achieved via the new possibility
of defining an action on the <tree> tag in the view definition. Known
bugs/inconsistency: depending on the model, this opens in edit mode, in
a new tab, ... behavior to unify in a future update.
- The 'PagePropertiesDialogManager' is removed since the code is in Owl
and we don't need page properties dialog on the list view anymore.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2889981
Part-of: odoo/odoo#98937
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_slides
After [1], the website "new content" dialogs were replaced by formView
dialogs of targeted content (blog, slides, product,...).
The goal of this commit is to restore the "course layout image preview"
on the "New Course" dialog for the "channel_type" field (as on the old
frontend dialog).
Remarks:
- The field was added on 'website' module so it can be used on other
website related modules if needed.
- Some CSS related to the old form was removed in this commit too.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
closesodoo/odoo#96346
Related: odoo/enterprise#29922
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
This commit adds an "on scroll" option for animations. In addition to
being triggered when they appear in the viewport, animations can now
also be triggered based on page scroll.
Animations are also improved in this commit, we add "intensity" option
and the dropdown with the list of animations has been split by adding a
new dropdown to choose the "direction" of the animations.
task-2862761
closesodoo/odoo#94119
Related: odoo/upgrade#3858
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the height of the element to be animated was
calculated without the padding of the element. That was wrong as the
padding needs to be considered part of the element.
task-2862761
Part-of: odoo/odoo#94119
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
