| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, the menu direction of header dropdowns was
related to the window width but it was wrong because of the right
panel. We also enable it in editor mode.
task-2312878
closes odoo/odoo#59783
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
*: portal
The dividers were removed with the new header templates but we still
needed them to know which items do not need to be folded in the
auto-hide menu. Instead of adding these dividers again, we added a new
class for these elements.
part-of: #59640
task-2312878
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before this commit, autohide menu was disabled in editor mode. This was
thus not really wysiwyg for users anymore.
part-of: #59640
task-2312878
|
|
Before this commit, the option to open dropdown on hover did not work
with mega menu.
task-2312878
closes odoo/odoo#59618
X-original-commit: 9b3b1c623867d3618220d8bd8a729701ae46448b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
For those templates, the transparent option was broken at some point:
we have to detect the hamburger is opened so that it is not transparent
anymore when opened.
Part of https://github.com/odoo/odoo/pull/59349
task-2327741
closes odoo/odoo#59458
Related: odoo/design-themes#395
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
When the header goes affixed, a compensating padding-top is added on
the content so that the scroll does not flicker. That padding-top was
added a bit too late and was enough to mess up the scroll on pages where
the content is about the height of the viewport: the header goes affix,
the scrollable content becomes smaller, the padding top is added, a
scroll is detected, the header is un-affixed since above scroll point
-> bug. If the padding top is added first, then there is no problem.
Note: the scroll effects code could probably use some refactoring.
Part of https://github.com/odoo/odoo/pull/56936
task-2312878
closes odoo/odoo#56936
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
*: web, web_editor
Since the right-panelization made with [1], the modals were not
compensating the body scrollbar when opened anymore and the backdrop
was misplaced. This commit fixes the problems generically, to support
modals with non-body scrolling.
[1]: https://github.com/odoo/odoo/pull/57975
closes odoo/odoo#58414
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
The affixed header was not properly repositioned in editor full screen
mode (introduced in 13.4).
closes odoo/odoo#58247
X-original-commit: 7502c8aa6e5422b1ecf446002e187fa2f7ca3aa7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
*: web, web_editor, portal, account, website_blog, website_forum
This is probably not ideal to move the scrolling behavior out of the
html element but this will be needed for the editor to not have a double
scrollbar on the right. This is actually also useful for the scrollbar
to appear under the purple odoo menu instead of its right.
This commit, if to be reverted in the future, however contains many
improvements to make the transition easier that should be kept: jQuery
and Odoo functions to be able to scrollTo a specific element, get the
top scrollable element, check if an element is scrollable, etc. Also,
some magic was done: if some code tries to scroll to a specific scroll
position via jQuery's scrollTop or animate functions on the html/body
element, those will still work as intended (obviously, using the new
utils to do that is however recommended).
This commit also reviews our scroll behaviors to make them more robust
and share the code.
Part of https://github.com/odoo/odoo/pull/57975
task-2344227
|
|
The class is supposed to be placed on elements which are absolutely
positioned over the main scrolling element at the top of the page. It
was wrongly placed on headers as soon as they become fixed while they
should have been placed on headers as soon as they become fixed *and*
over the main scrolling element.
Part of https://github.com/odoo/odoo/pull/57975
task-2344227
|
|
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
closes odoo/odoo#56427
Related: odoo/design-themes#346
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
|
|
*: web, portal
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
Co-authored-by: qsm-odoo <qsm@odoo.com>
|
|
This commit also add the possibility to indicate a "top gap" = a part
on the top of the header which is not supposed to be shown once the page
is scrolled (this is a leftover of the "preheader" task which was
cancelled for something better, but that JS code still made sense as a
possibility).
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
Co-authored-by: Benjamin Vray <bvr@odoo.com>
|
|
Since the images are now lazy loaded by default, the website menu was
not loaded correctly anymore when a mega menu was enabled and that there
was an image inside. Indeed, the menu loading waits for all images to
be loaded to compute the menu that should be in a dropdown when there
are too many. As the ones in the mega menus are hidden when the menu
is closed, the new lazy loading feature does not load them... which
makes the menu loading wait for something that is not being done.
This commit solves the problem by not waiting for images inside mega
menus. This could actually be done as a stable fix in stable versions
as there is no point waiting for those particular images in any case.
This will be only merged in master as it is not strictly a bug though,
at least for now.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
|
|
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
|
|
Do not update to main padding-top when opening an hamburger menu with
a fixed header. Close the menu hamburger if the page is scrolled.
Part of https://github.com/odoo/odoo/pull/51446
task-2229127
closes odoo/odoo#55045
X-original-commit: c06218408df4c8ec2fa3902e0cc03468c32dd36d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Bug introduced by [1]. When the header starts being animated, the main
padding-top of the page is adapted automatically with JS... but that
JS was actually starting a never-ending loop. This is fixed now.
[1]: https://github.com/odoo/odoo/commit/3defe35a0e4e2097115633797df6898ac2724c66
closes odoo/odoo#51726
X-original-commit: 07ed02608b8f4e3744c5e69c2651aa3df8bdd943
Signed-off-by: bvr-odoo <bvr-odoo@users.noreply.github.com>
|
|
Add an option to open dropdown menus on hover instead of click.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
|
|
*: portal
Adding a choice of several header behaviors (fixed, fade out with
scroll, etc.). Review the way those animations works in mobile/desktop
and now perform them without duplicating the header DOM element.
Also allow to hide of adapt the size of the logo when the page is
scrolled.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
Co-authored-by: qsm-odoo <qsm@odoo.com>
|
|
New snippet table of content with a sticky navbar with links related to
headings in content.
Part of https://github.com/odoo/odoo/pull/40690
task-2118980
closes odoo/odoo#40690
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
When you click on an anchor link, this commit ensures that the scroll
is in the correct place if there are fixed menus on the page.
Part of https://github.com/odoo/odoo/pull/40690
task-1894456
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
Before this commit, the code that was supposed to close the dropdown in the
navbar when scrolling was not working anymore.
Indeed, it would removes the `show` class from the `nav-item dropdown`
(dropdown menu entry) but not from the `dropdown-menu` (dropdown content).
Fixes #35320
closes odoo/odoo#36069
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
* = website_sale, website_sale_wishlist
The wishlist animation was not handling the affixed navbar and always
referring to the main one.
Now the animation will target the right navbar if we scroll down.
When the navbar is duplicated, the ids of the tags were kept which is
wrong and was producing bugs such as the wishlist button not showing up
on the floating navbar on the first product added to the wishlist and
the first issue. Now the id is removed from the clone and never used
in JS code. Its only purpose is for the xpath of the wishlist button.
When a product was added to the cart from the wishlist and the affixed
navbar was displayed, the product was hidden before the animation was
completed. This changed the height of the page and the animation went to
the middle of the page instead of the button. This is now fixed too.
task-2002122
closes odoo/odoo#34358
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closes odoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
* website_blog, website_crm_partner_assign, website_event,
website_event_track, website_form, website_forum, website_links,
website_mail, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_stock, website_sale_wishlist, website_slides,
website_twitter
While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
* portal, sale, web, website_blog, website_crm_partner_assign,
website_forum, website_event_track, website_links, website_mail,
website_slides, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_wishlist
The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
Now that the logo can be resized, the affix menu had to be adapted to
handle tall headers.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
|
|
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes #30564
|
|
Currently, in small devices, hamburger menu of the cloned navbar
is not scrollable due to fixed position.
This commit improves the behavior and makes the affixed navbar
scrollable, enabling user to navigate through all the available
menus.
task-1938637
closes odoo/odoo#32359
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
The previous code made sure we wait for images to be fully loaded before
initializing the auto more menu. But in some cases, it is not enough, we
also have to wait for fonts or even extra scripts. Those will have no
impact on the feature in most cases though, so we will only update the
auto more menu at that time, not wait for it to initialize the feature.
closes odoo/odoo#28684
|
|
When the user chose a very wide logo for the website navbar, it
overflew over the menu items (making the "+" feature look broken).
This in fact occurs since commit https://github.com/odoo/odoo/commit/4bc79da943c71e762e1f6dedbe3a641042bfef3f.
Its goal was to avoid top menu flickering due to that "+" button
feature. To do that, menu items were hidden with an height of 0 during
loading, then, once the correct number of items needed for the "+"
feature was computed, they were made visible to the user. Another
problem was due to the logo image loading. When it is not loaded yet, we
cannot properly compute the number of items which is needed. To solve
that problem, we fixed the size of the image container instead of
setting the height of the image itself.
But fixing the size of the image container only created a new bug: very
wide logos overflow this container. This commit solves all the problems:
1) The height of the image is set to be equal to the navbar links.
2) The height of the navbar is not forced, meaning that if the user
decides to change the height of its logo to go against (1),
everything will be adapted accordingly.
3) During loading, the menu items are still 0px tall, hidden and made
visible once the "+" feature is enabled.
4) The "+" feature is only enabled once all the navbar images have been
successfully loaded.
task-1878245
|
|
* portal, web
|
|
sale_report, ...
Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
|
|
|
|
* portal, web_tour, website, base
Before this commit, there were 3 different implementations for the same
feature: the "more" button in the community navbar, the "+" button for
the website menu and the "+" button in the enterprise navbar. As those
implementation were now broken with BS4, it was a good time to share the
code of those 3 features.
|
|
Now the nav structure is more declarative: the 'nav-item' and 'nav-link'
classes have to be put on related nav item and links. Also, the 'active'
class has to be put on links instead of items.
Same as for the navbar component:
- The navbar structure was simplified and meant to be more declarative.
- The navbar colors are also now handled by a different set of classes.
The 'nav-stacked' class was removed and replaced by flex utilities.
The set of classes for colors and nav styles also changed.
|
|
- The dropdown structure was simplified, allowing to get rid of the
3-levels structure induced by <ul/> elements and dropdowns can now
contain anything. The class 'dropdown-item' is now mandatory for
each dropdown clickable element. The class 'dropdown-item-text' can
be used to add same padding and style but without making the element
have a clickable look.
- Dividers now use the class 'dropdown-divider'
- The way dropdowns are opened and hidden also changed (before the
'open' class was added on the `.dropdown-menu` parent, now the
'show' class is added on both the `.dropdown-menu` parent and the
`.dropdown-menu` itself).
- JS-wise, no click event handlers can be put on `.dropdown-toggle`
elements anymore (instead, use handlers for dropdown events).
- Carets are automatically put on `.dropdown-toggle` elements, so this
commit replaces the `.caret` elements with this. This feature was
possible to disable but would prevent us from adding a caret with
scss. Also, this simplifies the DOM. The 'o-no-caret' class was also
introduced to allow using the 'dropdown-toggle' class on non-caret
elements.
- Also adapt the scss to use $caret-width instead of $caret-width-base
|
|
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
|
|
* portal
Review https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
- Some elements should not be folded in the "+" dropdown, like the login
button and related stuff
- Using pull-right instead of navbar-right (https://github.com/odoo/odoo/blob/392c91cda3133b921e9aca9a7b1c511231027438/addons/portal/views/portal_templates.xml#L37)
broke the mobile version of the menu
- Folded menu <li/> seemed too small (but it was only an illusion)
- On Chrome, the menu was sometimes not folded when it should have been.
This was because of rounded width calculations.
For the first point, the code has been made so that everything that
follows a divider is considered unfoldable.
|
|
* portal
When there are too many items in the top menu, the menu is broken into
multiple lines (especially on medium screen resolution). This commit
implements a system like in the enterprise backend: the extra items are
placed in a "+" dropdown menu at the end of the top menu.
Also, review the direction used to open dropdown menus. The default is
now left-to-right (while it was right-to-left before) and JS has been
added to determine the safe direction:
- If last item: to the left instead
- If would overflow the window: to the other direction instead
|
|
|
