| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
On an instance with only web installed.
A non-admin use had an error as trying to open the first app (which does not exists)
closes odoo/odoo#29687
|
|
This was necessary because the rendering was always determining
which app item should have the class 'active'.
This was an issue with the 'Click Everywhere Test': at the beginning
of the script, it gets the jQuery element that matches all nodes
`a.o_app` in the app menu. When an app item is clicked, it re-renders
the whole app menu, so that older referenced nodes are detached from
the DOM. As a result, clicking on them no longer works, because it
never triggers the MouseEvent `click .o_app`.
This commit fixes the issue by rendering the whole app menu once.
When an item in the app menu is clicked, it dynamically changes
the `active` app.
|
|
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
|
