*base_automation,iap,im_livechat,point_of_sale
This commit introduces a new file in core/utils: hooks.js
This file contains custom hooks (useEffect, useService, useBus...).
The useHotkey hook is tightly related to hotkeys, so it has been
moved to core/hotkeys.
closesodoo/odoo#74535
Related: odoo/enterprise#20003
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have an action in the breadcrumb (A)
Do an action (B) that has a button which spawns a dialog with a onClose callback executing an`history-back` event.
This may be useful when the action (B) acts as a selection buffer between (A) and the dialog.
(e.g. stock_barcode: execute `stock_barcode_client_action` from a picking)
Before this commit, the history-back event just closed the dialog without going back to the action (A)
This was because the wrong condition was used to determine if the dialog was still alive or not.
After this commit, the action (A) is displayed when closing the dialog from any point.
This makes the debug menu more natural to use, and makes the difference
between the "in-dialog" and "out-of-dialog" debug contexts explicit.
closesodoo/odoo#74346
Related: odoo/enterprise#19967
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Previously, push_state events triggered from withing window actions
inside dialogs would bubble push their state into the URL even while
within a dialog, this is undesirable as this can cause the URL to become
invalid (eg by pushing the id of a record from an entirely different
model)
This commit fixes that by simply checking whether we are in a dialog
within the adapter before calling pushState.
task-2602458
closesodoo/odoo#73720
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the modified test sometimes failed on runbot.
We need to wait for an extra tick, because the dialog might be
rendered in another animation frame that the crashing client
action.
closesodoo/odoo#73675
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since [1], the modified test was failing randomly on runbot. Here
is what happened when it failed:
- the initial action crashed
- we toggled the menu dropdown
- an error dialog was displayed -> the active element changed
- the dropdown was closed (due to commit [1])
- we asserted that the dropdown contained 3 items, but it was
closed, so test failed.
[1] https://github.com/odoo/odoo/commit/300ef9ac6fc92bcfd9c37a6088df650e0af32018
Before this commit, if there was a crash in a view or client
action during an update (i.e. the action is already in the DOM,
but an update triggers a re-rendering), the error was caught by
the action service, it wasn't displayed to the user, and the
action was re-rendered again (which could obviously result in the
same error being thrown again and again).
With this commit, we properly show the error, and we do not try
to re-render the action.
closesodoo/odoo#73507
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, when hovering a button with a bootstrap tooltip set on it
(form view with header button in debug mode) and then clicking while staying hover
the tooltip was not destroyed and there was no easy means to destroy it.
After this commit, any click within a legacy context remove any bootstrap tooltip from the DOM,
since popper and tooltip are not meant to be used in the future in a wowl setting.
closesodoo/odoo#73447
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
* google_recaptcha, mail, partner_autocomplete, point_of_sale, website
Now, to read session information, the module "@web/session" must be
imported. Not that, there is also the user service with all the user
information.
closesodoo/odoo#73201
Related: odoo/enterprise#19434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, two tests had undeterministic outcomes:
they wanted to assert something in DOM was present at the same tiome as an owl rendering
After this commit, the problematic asserts are removed and the tests behave deterministically.
closesodoo/odoo#73379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Do an action that will change the hash.
During this, change the url hash to load another action
Before this commit, the hash taken to load the second action was wrong, because the first
action pushed its state instants before the hashchange event is actually triggered.
This is because the hashchange event is triggered in a non blocking stack
(https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid)
After this commit, the right action is loaded with the right hash
closesodoo/odoo#72878
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* Add test name when logging missing action ids, makes finding out
which test causes the issue much simpler.
* Suppress the warning emission in the one remaining test which
triggers it, as testing invalid action IDs is exactly the purpose of
the test.
on a legacy form view, do an action in target new
The view in target new should, during its onchange, trigger a ValidationError
Before this commit, the dialog_container was stuck in an error loop.
This was because the received error was never an instance of Error, rather it was
a legacy error event. So it was never transmitted upstream were the ErrorHandler could remove
the dialog in error from is dialog array.
After this commit, the ValidationError mesage is displayed.
This commit additionally fixes another issue:
An action in target main that failed to render erased the whole DOM. This is not what we want,
at least for now. Imagine a list view, open a record, this record fails to load. We still want to be
on the list view, not in a blank state.
Open a action in target new that you'll know will fail to open.
Make sure you put an onClose callback when executing doAction.
Open another action in target new, that will succeed.
Before this commit, the onClose of the first dialog is executed, while it should not.
Indeed, if the dialog fails, the whole business flow is invalid altogether
and no more business operation (in the onClose) should be executed
After this commit, the onClose callback of the failing dialog is not executed.
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, all actions, even those executed in target
"new" (i.e. in dialogs) updated the document's title. Actions in
dialog should not do that.
closesodoo/odoo#72526
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The activities systray item didn't work anymore. Nothing happened on
click.
It was because the do action event was never caught. The systray item
logic had a different flow and didn't go through the ViewAdapter code.
We fix this by adding a listener on window (through legacy service
provider) to execute this code when the do_action bubbles up.
Instead of using the legacy service provided, we could have done this
in the SystrayItemAdapter, but we then have the legacy environment and
would need more work for the same result.
closesodoo/odoo#72406
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the push state from client actions to the URL did
not work properly:
1. the action.params key was ignored
2. some "reserved" keys (active_id) were not handled properly
3. within a legacy client action, the call to parent.do_push_state did not work
After this commit, all of those work properly letting discuss in particular have the right URL
It is worth noting that in the full wowl stack, that the right way to push something
in the URL from a component is always to call the router service's pushState when the component is mounted
closesodoo/odoo#72408
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, an error in the rendering of a client action or view
would not be properly cleaned: the action container did not catch any
error, so owl would destroy the UI.
With this commit, we simply catch the error, and empty the content of
the action container.
Before this commit, the switch from a multiple view (list, kanban, ...)
to a custom form view was not correctly done. The form view displayed
was not the custom version but the default one.
This problem is caused by the filter applied on viewSwitcherEntries
which removes the form views because they are not a multiple view.
To solve this problem, we will add the missing form view in the
actions.views given to the legacy view.
closesodoo-dev/odoo#958
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, effect service provided two functions:
create(type, params)
rainbowMan(params)
Now, it provides one function add which is create but renamed
rainbowMan function can be called by doing:
service.add("rainbowman", ...);
closesodoo-dev/odoo#969
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In legacy, doAction can be passed the `controllerState` key, which contains `searchModel`
and `searchPanel`, that an AbstractController can export.
This commit re-implements this in the action service.
Some services are coupled with a Component. Usually the service
handles the state of the system, and the Component displays or uses it.
To enable the communication between the service and the component
while making it private, the services should add themselves their
Component in the relevant registry, with the proper means of communication
passed in props.
This mechanism relies on c1d49d494e0ae3a94b3943186eb6d1ebd7b98a6e
BUG: Begin on a multi record view (list, kaban), change the url param "view_type" to form. A controller
adapter component would fail to mount and and promise would be pending for ever, freezing the webclient.
WHY: The new webclient, in the specified case described above, would set the recordId to false when switching
to the single record view without providing a record id in the url. However, the legacy views expected a value
of undefined.
FIX: In an adapter layer, the legacy views adapter, we check for the recordId being set to false. When it is,
update this value to undefined.
closesodoo-dev/odoo#933
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
From a list or kanban view, quickly click multiple times on a
record or on the Create button: a lot of bad stuff could happen
from there (e.g. crashes, form view that could not be open
anymore afterward).
The reason was that we destroyed the legacy form view whereas we
shouldn't, as it was still used. In more details, when we clicked
first on a record to open it, we created an owl Component to
instantiate and wrap the form view (legacy). When we clicked a
second time, we another owl Component was instantiated and the
first one was destroyed. As an unwanted side-effect, the legacy
form view was destroyed as well, but the new controller wanted to
reuse it. From that point, anything bad could happen as we were
trying to use a destroyed widget.
closesodoo-dev/odoo#941
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
A client action can be a function. This function may return another
action to be executed afterwards. This function may also be async.
This is for instance the case of the studio client action. Before
this commit, the code handling it directly called doAction with the
promise as action, which could lead to unexpected results. For
instance, studio tours sometimes fail to load the studio client
action.
closesodoo-dev/odoo#935
Related: odoo-dev/enterprise#169
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The behavior of some components like the Dropdown component depends on the ui service that records
(among other things) what is the "active" element in the page. For instance a dropdown can close/stays open under
certain circumstances if it is in the active element or not. The fake ui service created by makeFakeUIService
was not managing properly the active element. Since we want to avoid code duplication and that there was no real
need for a fake ui serice, we simply drop the helper makeFakeUIService and use the real ui service everywhere.
Until now, if a dialog was opened using the action service with an
on_close callback, this callback wasn't called if the dialog was closed
without using the action "ir.actions.act_window_close".
Now, the on_close callback is called after the dialog is closed.
closesodoo-dev/odoo#929
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Until now, the action container opened/closed an action dialog directly
on the template, and relayed on the bus to communicate with the action service.
Now the action service opens/closes the action dialogs using the action service.
To do this, a new close method is created on the action service.
This commit also separates the code of dialog service and dialog container to
be more standard.
closesodoo-dev/odoo#900
Related: odoo-dev/enterprise#156
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the web client was not behaving in an
optimal way when trying to load an invalid action.
This scenario actually occurs quite frequently for developers:
- have odoo open in a tab
- drop the db, reinstall odoo with possibly different addons
- reload the tab (so, it has an action_id in the url)
Doing so would most likely lead to an invalid action_id, which in
turns displayed a traceback, because we assumed in the code that
the return value from the /action/load call is valid.
With this commit, we handle this case, and also display an empty
screen with a notification to give some feedback to the user.
This commit renames the DebugManager to "DebugMenu", changes the
structure of its registry and the signature of its hook (useDebugMenu).
In the previous DebugManager:
- the "debug" registry was flat;
- new items were declared and created with the "useDebugManager" hook;
- these items were arbitrary functions returning a set of items.
The problem with that system was its extensibility, meaning that no
external module could hook on these arbitrary functions passed to the
hook.
In the new DebugMenu:
- the "debug" registry has multiple levels:
> root: "global" items, found in most debug menus
> subcategories: each subcategory has a name corresponding to the
context it's instantiated in (e.g.: the "view" subcategory will only
contain views-related debug menu items)
- all items are pre-declared in their corresponding category, and either
return a debug menu item or null;
- the hook activates/deactivates categories, and passes a context which
will be used by the item factories (passed as argument).
Before this commit, the router service used in tests was almost
entirely mocked and some of the mocked features didn't correspond to
their original counterparts.
Now, the actual router service is used in tests and the browser object
is mocked instead, allowing to correctly test the routing features.
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>
Aaron Bohy