This mostly an issue when trying to run just the tests of `web` (aka
`-iweb`) with only community modules available,
`TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the
ready code times out:

    AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy

and the test suite fails.

The ready code simply checks that `odoo.isReady` is set. The web
client sets `isReady` when `webclient_started` is
triggered (specifically in `_onWebClientStarted`, which is the handler
for that event).

[The community web client only triggers `webclient_started` at the end
of `doAction`][0] meaning the community client is considered ready
until after the first action has executed.

[The first action is executed by `show_application`][1] whose process
is the following:

1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action

When installing only `web`, the only menus which could be available
are Apps and Settings, and the demo user has access to neither. This
means the demo user has no applications, and opening the first app is
a no-op ([`openFirstApp` has a case just for that situation to ensure
it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is
never set, and the tour never runs.

Fix by updating `openFirstApp` to return *whether* it opened an
application, and in `show_application` the last fallback if even
opening the first application failed is to just declare the web client
ready.

While at it, rewrite `show_application` using ES6 facilities and
flatten and linearize it using guards. This means the code pretty much
tracks the process described above, with one step added:

5. otherwise complete the webclient's startup

[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174

[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107

[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46

closes odoo/odoo#69962

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

This commit aims at fixing a random bug on the runbot.

When loading the webclient, if there is no hash, a rpc is done to
read the default action of the user. When this rpc comes back, we
execute the given action (if any), or the first action (typically
Discuss). The navbar is displayed as soon as possible, it doesn't
wait for the first action to be executed. This means that the
user can open the user menu and click on 'My Profile' before the
first action is executed.

Before this commit, if the user clicked before the read rpc on
'res.users' returned, the default action (or the first) one, was
executed, even though the user clicked on 'My Profile' and thus
asked for a specific action. So basically, the user form view was
briefly shown, and then replaced by the default or first action.

Whereas this is a very rare usecase in practice (the timing is
really short), this sometimes made the totp tour fail. However,
even if it is unlikely, the client must be robust and correctly
react to concurrent requests.

This commit fixes the issue by executing the 'My Profile' action
in the DropPrevious. That way, if any 'doAction' is performed,
other pending operations (also done in DropPrevious) are dropped.

This commit also ensures that the "brand name" part in the navbar
(containing the name of the current app) is hidden when there is
no current app, as in the scenario described above, we land in
a webclient with no current app. Note that not being in an app was
something that was already handled, but not at startup.

closes odoo/odoo#57840

Related: odoo/enterprise#13277
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Currently, the method `on_attach_callback` is never called on any Widget in the
systray.

Calling `on_attach_callback` is required if any systray widget uses an OWL
component via the ComponentWrapper. Without the callback, the component is never
considered mounted to the DOM and no event handler is triggered.

closes odoo/odoo#46566

Related: odoo/enterprise#8887
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Issue

	- Install Accounting
	- Resize your window to have the more menu
	- Refresh the page to make the JS working correctly
	- Click on the item on the left of the more menu
	- Do not close the menu just hover the more menu
	=> It doesn't appears (the .show class is on the last <li> child instead of the parent)
	Click on the more menu
	=> It appears but small & with items broken

Cause

	Without the :first, all the more menu dropdown where toggled

Issue

	Add :first to the target to toggle

OPW-2178843

closes odoo/odoo#46553

X-original-commit: 55a4a834461446a070ad06d1b24d67fbc27799a1
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>

While hovering in the systray a menu dropdown can only be open if user currently on his parent menu.

It should close when user hover on another systray menu.

Task: #1959678

closes odoo/odoo#32322

Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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>

There used to be no processing done at all when loading the client
from an url missing a menu_id and from which the menu could not
be inferred from the action_id. This resulted in the app name
button in the menu being empty but still present and not bound to
any action. Clicking on it triggered a traceback.

This commit stops ignoring the case when the menu cannot be
inferred from the action and hides the entire menu and submenus
for this particular action. They will be restored when entering
an action from which a proper menu can be inferred.

closes odoo/odoo#27791

Revision on https://github.com/odoo/odoo/commit/b7cf456560dc4fd7c1217ba90f0b5609466ede50

The commit above assumed the function `change_menu_section` was
mistakenly removed. However, it was turned into a handler function
and renamed according to our JS guidelines `_onChangeMenuSection`.

This commit removes the duplicated logic by removing the
function `_onChangeMenuSection` and using `change_menu_section`
as the handler for the bus event `change_menu_section`.

closes odoo/odoo#27809

Revision on https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242

The commit above changed the menu in community, so that it
looks like enterprise. To do so, it copies the menu management
from the enterprise repository to the community repository.

Some code about the home menu has been removed, since it is replaced
with the app menu in community. However, some functions have been
removed by accident, such as `change_menu_section`.

Closes #27436

The navbar in community now looks more like the navbar in enterprise.

Here is a sum-up of the changes in community:

- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
  now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
  now located in the middle part of the navbar.

The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.

Task-ID 1878649