Wednesday, April 28, 2021
3 changes · master
Resolved issues and error corrections
This fixes how the Indian localization adjusts the unit of measure screen so the intended fields or settings appear in the correct place. It helps avoid display or configuration issues for users working with India-specific business data.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web client now completes startup even when a user has no accessible apps or menus. This prevents test and loading timeouts in limited community-only setups, improving reliability for restricted users and lightweight installations.
Original PR description
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…
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-L46This update fixes small issues in the account consolidation trial balance screen that could cause controls to behave inconsistently. It also cleans up the underlying code so the screen is easier to maintain and less likely to be affected by browser changes.
Original PR description
* sets attribute on `self` but `self` is not defined locally, so really defines them on `window`. These attributes seem unnecessary (one's just being used twice) so just inline it all and remove `init` override * not to mention one of the use sites did define a local `self`, so it was always `undefined` * use the local `e` parameter, rather than the deprecated `window.event` global * don't set buttons as instance attributes, that doesn't seem useful, and use jQuery's fluent API * while at it, modernize code (shorthand methods, splats)