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>
Short summary:
- People can now use the snippets option to show/hide based on country
- We never use / test / maintain this feature, if it still works since
its introduction 4 years ago that's by luck
- It is probably barely used, we never got a single question or issue
about it
-----------
When we introduced the multi-website feature, it came with 2 main use
cases:
1. Multi website by domain -> Every website has its own domain and based
on that we serve the expected website
2. Multi website by geoip -> Multiple website can have the same domain
and based on GEOIP/country we serve the expected website
We never really supported, highlighted or promoted the geoip case.
We actually never use it ourselves when doing tests, and we don't
consider it when doing specs / improvements.
At most, only a very few people know about it in Odoo.
That GEOIP case is probably not useful at all, as displaying a whole new
website based on lang is not easy since nothing can be shared out of the
box -> Every website has its own COW records.
For instance, one could think of having its main website A and another
website B on which he just added 3 products specific to that website B
country.
But such a case won't even work properly, as any adaption on website A
won't be reflected on website B (design, theme etc).
closesodoo/odoo#99938
Related: odoo/upgrade#3892
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
Commit [1] introduced t-cache on the footer making it cached depending
on its website id. This is wrong as the footer can be visible or hidden
depending on the page it is currently rendered in.
This commit adapt the t-cache so that the footer is cached based on the
page.
Steps to reproduce:
- Go in edit mode and click on the footer
- Turn off "Page Visibility"
- Save
Footer is now hidden on every page depending on which page rendered it
first.
[1]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466dclosesodoo/odoo#99832
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
The history of this one is kind of tricky, to say the least.
A fix in the theme install process was done in 14.0 with [1].
It came with a `standalone` test in the `design-themes` with [2].
It had to be a `standalone` test since it is playing with module
operation, which is forbidden in the regular testing suite (sadly).
Since this new test was the first `standalone` test in the
`design-themes` repository, it actually wasn't even properly tested for
months before we realized it. It was missing some runbot configuration
in the nightly build to include the `design-themes` repository in the
standalone testing suite.
Once the runbot configuration was correctly fixed, the test wasn't
working anymore in 15.3 and later version because of some change in the
httpocalypse [3] which made the `MockRequest` not behaving as expected.
Indeed, with [3] the request's context had to be updated through
`update_context` which wasn't adapted/working with `MockRequest`.
Then, since [1] (merged in 14.0) was ported in saas-15.3 at [4] (where
[3] also exists) it was the first time a test using `MockRequest` was
ending up calling business code doing a request's context change.
The business code doing `update_context` and called through the test in
`MockRequest` was then not doing anything and not changing the
`context`. The test was then failing despite the behavior/normal code
base working properly.
This commit makes the request's context change working with
`MockRequest`.
Some people think `MockRequest` should disappear, but right now that's
how it is, we are still using it as this is really useful to be able to
test business code in a frontend context without going through a tour.
For what it's worth, multiple time the community asked us to move it
outside the website module, but also multiple other internal team in
odoo. So, while it might be better or not correct in some cases (mainly
python super), the tool is useful.
[1]: https://github.com/odoo/odoo/commit/b8a24efa71daea1f96465b780f4f0e384ce74703
[2]: https://github.com/odoo/design-themes/commit/4de16d85b7f7d69212576eede82e8a15190d357b
[3]: https://github.com/odoo/odoo/commit/f61aa39ff1190f66cebb8efb8432723214932161
[4]: https://github.com/odoo/odoo/commit/14387f36438b731753e2e7169f54865b123cdcfaclosesodoo/odoo#100070
X-original-commit: 885ce02a15dc093ff98822f80b22c4415fa9cceb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@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
This commit improves the overall 'website_sale' sidebar design and solve
minor usability issues.
Design overrides has been removed in order to allow customization
thought SCSS variables and ensure consistency between components.
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>
Partial revert of fba6ea5a47
If the designer group is not given automatically to all admins,
they are not able to go through the website onboarding automatically
launched after the website app installation.
Task ID - 2936569
closesodoo/odoo#98542
Related: odoo/enterprise#30626
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
lstrip remove each letter, and not only once in this order.
So a google console key like googleeef88156 will be never trusted.
'googleeef88156'.lstrip('google') = 'f88156' and not 'eef88156'
Now we ensure that it starts with google or ends with .html and remove
exactly what we know.
To replace with removeprefix/removesuffix once we have py3.9 as minimal
version.
closesodoo/odoo#99776
X-original-commit: 44c08f18de9b2f25d1c716319ad287a409d2384d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@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>
- use util method already used in regular theme selector screen
- theme_common is already in hidden category, no need to exclude it
- searching on theme category rather than `theme%` name
- move the uninstallable check in the util, no reason to show those in
the regular theme selector screen either
Fixes#92125closesodoo/odoo#99099
Related: odoo/design-themes#586
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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
Since [1] the 403 pages displayed when a website page is restricted to a
different group of users is the default one instead of the website one.
After this commit 403 fallback errors are rendered by the default error
rendering.
Steps to reproduce:
- Go to a page. (e.g. "Contact Us")
- Select "Page Properties" in the "Pages" menu.
- Go to the "Publish" tab.
- Define visibility as "Some Users".
- Select a user group. (e.g. "Administration / Access Rights")
- Access to the same page in an incognito window.
=> The displayed 403 error page was the generic one instead of the
website one (with the navigation header...)
[1]: https://github.com/odoo/odoo/commit/eb7eecec976570ae3301c17a04adc9c110d5b14a
task-2963843
closesodoo/odoo#99671
X-original-commit: fc0a0c2ccea83b3a9a5df0e300eac1fe7eb7a2a2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
website: get_base_url was not working with unprivileged users
Before this commit, when a unprivileged user tried to generate a report
(in sale for example), he could not access to the field website_id on ir.ui.view
An access error would be raised. This commit allows to read the base_url for all users.
Misc: UI for sale order templates
Before this commit, the sale order template information was not clear enough.
Note: these changes were merged into a single commit to ease the manual FW port of
changes in 15.3 for sale_subscription
taskid: 2942621
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@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
A "page manager" list view will be created for key models in other
apps. This commit prepares a convention that all other apps will follow:
a dedicated file for the views related to this feature, named
"website_pages_views.xml".
task-2889981
Part-of: odoo/odoo#98937
This commit adds the possibility to use a grid to move and resize
columns inside some building blocks.
More precisely, for the majority of the building blocks having columns,
it is now possible to toggle between the current layout (= normal mode)
and the grid layout (= grid mode). The grid mode can be triggered in
two ways:
- by using the "Grid" button in the options (when available),
- by dragging a column using the move handle.
The toggle places the different columns in the grid as close as
possible as how they were placed in normal mode.
The normal mode is toggled back by clicking on the "Cols" button (when
available).
Since the move handle is now used to trigger the grid mode, the columns
in normal mode are now moved using the arrows.
NB: to avoid any confusion with the word 'column' in the explanation
below, the BS column will be called 'grid item' and the grid column
will be 'column'.
When in grid mode, the building block is a grid with 12 columns and a
number of rows which depends on the height of the grid items.
This mode offers the following functionalities:
- Moving a grid item:
When a grid item is dragged, it can be placed anywhere in the grid. If
it is dragged towards the bottom, new rows are added in the grid to
increase its height and to place the grid item lower. These added rows
are removed when it is dragged towards the top.
A grid item can also be placed over an other item (-> they can overlap)
and their order can be changed using the two new buttons to place an
item in front of/behind all the others.
A grid item can be moved from a grid to another, and also from a grid
to a building block in normal mode.
- Resizing a grid item:
A grid item can be resized vertically, horizontally and diagonally with
the help of the grid. When resized towards the bottom, new rows are
added in the grid and they are removed if it is towards the top (like
with the drag and drop).
- Adding elements:
The "Add Elements" option allows the user to add as many images, text
blocks or buttons as wanted in the grid.
Inner contents can still be dragged and dropped inside a grid item.
- Changing the padding of the grid items:
The padding option allows to change the vertical/horizontal padding of
all the grid items at the same time.
- Mobile view:
When in mobile view, the grid items are not in a grid anymore (the
display is back to flex) but they keep their grid properties. They
cannot be resized, nor dragged and dropped but they can be moved using
the arrows. By moving this way, it does not impact the desktop view.
task-2825241
closesodoo/odoo#93144
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: 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
Arthur Detroux (ard)