Since [1], the test suite waits for 5s to start running. It's
really annoying when you run the suite in your browser, to debug
a single test or a sub suite. Waiting for 5s to determine whether
all modules can be loaded or not is not necessary anymore since
all assets coming from the same bundle are loaded in a single
file, even in debug=assets. This is true under the assumption that
there's no js module in assets_common requiring a module in another
assets bundle, which seems reasonnable.
[1] 468eb84fb4closesodoo/odoo#83805
Signed-off-by: Géry Debongnie <ged@odoo.com>
The new handler changes the behavior of `wait_ready`: before it would
wait for the `ready_code` to be `true` *or a settled promise*.
Now it waits for `wait_ready` to resolve to true, whether it's a
promise or not.
Part-of: odoo/odoo#77735
Previously, when an Error was thrown inside an async module, that error
would not cause boot.js to log information about missing, failed or
rejected modules. This is because we were only using guardedCatch to
mark modules returning a rejected promise with something other than an
error as rejected, but the case where a real error was thrown was not
handled, which left the job to be forever pending.
This commit fixes that by catching real errors after the previous
processing, and treats it like an error in a synchronous module.
This commit is the first phase of the conversion of the web/ JS
codebase to the owl framework. The impact of this commit is two-fold.
First, it rewrites the framework part of web with a new system of
services and registries. Services allow to execute code (e.g. do rpcs,
setup things) before launching the application. They can also expose
an API to be used by other parts of the application (e.g. a notification
service would expose a function to display notifications). Services are
often a good extension point for external modules that want to execute
code at webclient startup. Registries offer another way to extend the
application. They provide well designed extension points to add
elements/behaviors from the outside (for instance, to add a systray item,
an error handler...).
Second, this commit initiates the conversion of the webclient to owl
with a top-down approach, around those notions of services and registries.
The root of the web application is now an owl application. Among others,
the WebClient, ActionManager, Navbar, UserMenu, DebugManager, Dialogs,
services (e.g. notification, ajax...) have been converted to the new
framework/architecture.
Legacy views and client actions are still supported (and used). They
will be converted in the next months, and at some point, the support
will be dropped.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
Aaron Bohy