Before this commit the Device visibility option was on its own row
inside the options panel.
This commit moves the buttons of the Device visibility option before
the dropdown inside the main row of the Visibility option.
task-2900730
closesodoo/odoo#102154
X-original-commit: 82000acfb6f8c7884994135413dcddac5441f8b4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, in edit mode, it was not possible to close an open
dropdown in the header anymore.
This was due to BS5 (merged at [1]). Before, the 'show' class was added
to the dropdown menu element (the element with the 'dropdown' class).
But that changed: the 'show' class is now added on the button (the
element with the 'dropdown-toggle' class). And as in edit mode the
openings/closing of the dropdowns are handled manually in the header, it
no longer worked correctly.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-3001198
closesodoo/odoo#102145
X-original-commit: f3e1dc52356164453f72827e3dc87ad903df3d0e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the dynamic snippet would only start sliding after
the first interaction.
This commit makes it slide right away.
task-2677203
closesodoo/odoo#80128
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the Dynamic Snippet options would modify the DOM
at places were it is not supposed to.
PR [1] aimed at making it more stable, but the changes required to make
the option conform to the framework cannot be done in stable as some
methods' signatures needed to be changed (Changing a sync function to
async).
This commit aims at making the option follow the flow of an option:
- Modify the target's DOM either on build or on a change of option
- Modify the UI either during willStart or updateUI
To do so, the methods that fetch the template data needed to be split
from the methods that creates the buttons.
The benefits of this commit are that the option is less likely to cause
race condition and errors while performing its tasks.
[1]: https://github.com/odoo/odoo/pull/82222
task-2677203
Part-of: odoo/odoo#80128
This commit improves the design of dynamic products templates.
It introduces templates using multiples rows and fine tunes the
design of the other ones.
To make thumbnails work in the template selector, an extra
data-attribute can now be processed by the snippet option.
- data-thumb: it references the location of the thumbnail for a
template. If present the option will show the svg / img.
If not it will display the name of the template.
task-2677203
Part-of: odoo/odoo#80128
Co-authored-by: Arthur Detroux <ard@odoo.com>
*: website_sale
Previously, on the debug dynamic snippet, you could choose a product
filter and a template that had an add2cart button but that button
would not work.
This commit fixes that by creating a widget per card and moving the
card specific code to this widget.
task-2677203
Part-of: odoo/odoo#80128
*: website_blog, website_event
Commit [1] introduced new templates. This commit's goal is to build on
that template system to provide more flexibility for designers.
It adds new data-attributes to set on the first node of a template.
- data-row-per-slide: Allows for the template to tell a dynamic snippet
carousel how many rows of cards it should display.
- data-arrow-position: Allows for the template to tell a dynamic snippet
carousel where the arrows should be positioned.
(for now just bottom, or side)
- data-extra-classes: give the template the possibility to add extra
classes to the dynamic snippet instead of just the card.
This commit also removes options to select the amount of elements
displayed on each row. This is now only changeable through templates, or
by directly editing the snippet's DOM through debug tools. This was done
to reduce the amount of options visible, so that the user just chooses
a template and it is ready to go.
[1]: https://github.com/odoo/odoo/commit/49bd79b0bdca76415780bdfa199195371c2692e5
task-2677203
Part-of: odoo/odoo#80128
In some place the search params are mandatory in the route.
We now add the search and hash params to the editedObjectPath to
avoid having an error when trying to go back.
task-2993826
closesodoo/odoo#101996
X-original-commit: 2bed20392084bcbec2683939e5659b03e3ea7acf
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_hr_recruitment
After [1], the multi-edit was added on the pages list views not using it
except 'hr.job' records since editing the 'Department' field leads to a
traceback.
The goal of this commit is to fix this issue by setting an invisible
'company_id' (to be available in domains since necessary to change
'Department') and add multi-edit on the view.
The 'home' icon for 'home page' records on list view should be hidden
after this commit (on multi edit mode) to edit the fields correctly.
[1]: https://github.com/odoo/odoo/commit/be58687284884550cc4e6c2ac7255abee4eb1125
Related to task-2889981
X-original-commit: d101be46a2a9c392e2d63f491fcc5ccec2d65c78
Part-of: odoo/odoo#101814
Before this commit, the WebsitePreview document title was not completely
replaced with the iframe's one: it was still prefixed by 'Odoo - ' by
the title service.
Now, the WebsitePreview, introduced in [1], is adapted to remove the
'zopenerp' part when replacing the title (and adding it again when
unmounted). While doing this, the backend's favicon is also changed with
the frontend's one, to be consistent with displaying the frontend
document title only.
This commit also adds an effect on the Optimize SEO dialog, so that the
document title matches the user's input.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#101972
X-original-commit: 52ec7d1279144b9cd38f8444648b8246df694b9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Before this commit, for the following flow:
- Add arabic language (or any other rtl language),
- On one of the websites, set it as the only website's language,
- Reload and go to the client action,
=> The frontend is correctly displayed in rtl,
- Click on edit,
=> The frontend, in the iframe, is reverted to ltr,
The WysiwygAdapter, introduced in [1], was not passing the correct
direction option to the OdooEditor, which would revert the editable to
the default 'ltr' direction.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
X-original-commit: 2f463ca65b149122c85a04b20b4f82e0be479fc8
Part-of: odoo/odoo#101972
Before this commit, the Editor Menu was confusing when opened for a
translatable website: it would list the menus in the user's language,
not in the displayed website's language.
First, this commit shows that menu only for websites in their default
language, as the user should edit his website structure in the default
language.
Secondly, the 'get_tree' and 'save' requests on the website menus are
done with the website's language, not the user's language.
This commit also fixes a bug introduced with [1]: the website override
of the start method of the SnippetsMenu was incorrectly done.
In translate mode, it should not activate snippets on clicks, otherwise,
the LinkPopover was instantiated when clicking on navbar menus, allowing
to edit the menus from the translate mode, and breaking it.
[1]: https://github.com/odoo/odoo/commit/df1869153a90898bad3e0b61e5fc43a9ed3d59c9
task-2687506
X-original-commit: 4266966a9b0fa452b5991d9bea0fe914aca85f4d
Part-of: odoo/odoo#101972
This commit fixes 2 issues with the position of the dropdown with the
suggested links in the url picker input of the snippet options. (e.g.
redirect url input of the countdown snippet) and the one for the input
of the link editor.
1- Before this commit the dropdown went over the input while editing the
url.
2- Before this commit the position of the dropdown (when above the
input) was a little too low if there were images in the dropdown. It was
because the images are loaded after the positioning of the dropdown and
no height was defined for these images.
task-2900529
closesodoo/odoo#101815
X-original-commit: 774a42ff18651a20b09a5e34222665216b19c8ec
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The cookies bar default templates are designed in order to guide the
user towards selecting the option that will provide the best user
experience.
This raises security concerns (see discussion in PR for details).
This commit adapts the buttons of the default cookies bar templates so
that both options are shown with the same style, forcing the user to
take a decision.
task-2800976
closesodoo/odoo#101845
X-original-commit: 32d88f47a67679b7e90fa58e25089846484b48ca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.
This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.
It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.
What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.
Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).
Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.
Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
differentiate essential and non essential cookies and to allow user
to accept only one or both (task-2800976).
Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
The German law about this
Closes#83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)
Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt
closesodoo/odoo#101826
X-original-commit: b06ce21eba6388ce34bbffffadcb489f0e8557dd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, the WysiwygAdapter would crash with a TB if an
event reached the wysiwyg_adapter when the websiteRootInstance was no
longer accessible (in case of a PageReload while an event in the mutex
is still trying to fire events).
Note that normally, events should not be sent when the
websiteRootInstance is gone as the editor should be destroyed. But
since "widgets_start_request" triggers also implement a "onFailure", it
seems right to use that in such case.
closesodoo/odoo#101687
X-original-commit: 0cc206f94151e2da646064e265e14a341daff58a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Use system fonts for backend and web-editor's UI.
This commit removes references to proprietary fonts and allows the OS
to use the system ones. The aim is to reduce http request and the
general footprint (see enterprise counter-part).
The new font-stack:
- apple-system (San Francisco): iOS Safari, macOS Safari, macOS Firefox
- BlinkMacSystemFont (San Francisco): macOS Chrome
- Segoe UI: Windows
- Roboto: Android, Chrome OS
- Helvetica Neue: old OSX versions
- Ubuntu: Ubuntu
- Liberation Sans: Linux (others)
- Arial: Any
- sans-serif: General fallback
This was actually already introduced for the website default theme and
as a general option with [1] but it was not complete: if reaching the
need to use Roboto of the font stack, the repo Roboto was used instead
of the potential system one. It was not shown during testing with the
previous font stack. With the new one, on Ubuntu, it was revealed as
the Ubuntu font comes after Roboto.
[1]: https://github.com/odoo/odoo/commit/c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
task-2995248
closesodoo/odoo#101533
X-original-commit: 9f8f8f2ef88aee746819469c918b2d31ec29d031
Related: odoo/enterprise#31985
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
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
Benoit Socias