| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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>
|
|
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
|
|
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
|
|
|
