Before this commit, the `on_attach_callback` and `on_detach_callback`
callbacks are not called all the time on the `Dialog` widget when it's
attached/detached to the DOM. Relying on those callbacks could result in
unpredictable behaviours.

To be more precise, the `on_attach_callback` isn't executed on a regular
Dialog#open() call. But Dialog spawned by the ActionManager will execute
it.

This difference prevents from properly binding those callbacks later on
through an extend or include of the Dialog widget as we have no way to
know if they have already been called or not (e.g. which can result in
calling them twice).

This commit normalize this situation by ensuring that the
`on_attach_callback` and `on_detach_callback` callbacks are properly
called by the Dialog widget and allows any extension of this widget to
rely on them. Therefore the ActionManager is adapted accordingly.

opw-2438534

closes odoo/odoo#64780

Related: odoo/enterprise#15849
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

In a dialog, a button with `close="1"` should close the dialog when clicked.
It currently only works if the dialog is a subview.

closes odoo/odoo#55200

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: fleodoo <fle@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>

closes odoo/odoo#52826

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

When the web client is completely ready, it triggers an event "web_client_ready" on the bus
Some Mail OWL components rely on that mechanism to be mounted
i.e. DialogManager and ChatWindowManager

When eveluating the action to display at startup, the webclient mechanism
implies that we push the location hash each time a relevant data is available
e.g. menu_id etc...

Now, before this commit, since the hashchange handler is bound before that evaluation
it is actually triggered each time the JQuery bbq pushed a url state (this is in the API)
doc: http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html#jQuery.bbq.pushState

This undercuts the initial loading promise chain to finish and the event "web_client_ready" was never triggered
preventing everything that relied on it to be mounted

After this commit, the webclient is artificially finalized, with the help of a new custom event
"webclient_started". So the event web_client_ready is triggered,
signalling to everyone it is in the dom and usable

A lot of bug persist though: the start() of webClient sometimes returns a rejected promise

It is worth noting that the hashchange mechanism is largely outdated and will change
in a more reliable way in the near future with the conversion of the webClient to OWL
the drop of JQuery BBQ and the direct reliance on window.history.pushState
doc: https://developer.mozilla.org/en-US/docs/Web/API/History/pushState#:~:text=The%20state%20object%20is%20a,the%20history%20entry's%20state%20object.
and on the window's "popstate" event
doc: https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event

This commit must be applied on the enterprise webclient too

closes odoo/odoo#52892

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

Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.

Part of task 2196029

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

Before this commit, after the introduction of OWL, for some reason,
maybe because the session is ready earlier or later, the webclient is
opening the first app sightly earlier than before, making it too early.

The click_all failed actually because, in the initialization of the
webclient, it does a read on read user, protected by a drop_previous
it tries to start the first applictaion, when this happens, the hash
changes
==> because the hash changes, it tries to open an application, with is
also protected by the same drop previous, this discarding the result of
the read and preventing the then callbacks of the read to happen.

After this commit, we are declaring that the client is ready after the
actual load of an application.

closes odoo/odoo#41695

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Sometimes, it might be useful for an action (e.g. a client action,
although this may be used by standard views as well) to include custom
values in its state. Since the state of a 'fullscreen' action is pushed
in the URL, this means that it is possible for the action to resume its
state properly upon refresh of the page (before this commit, only some
standard information were pushed to the state - action_id, menu_id, etc.
for window actions and action's name, active_id, active_ids for client
actions).

By implementing the `getState` method, an extension of the action mixin
can thus push any state it wishes to the URL.

closes odoo/odoo#39529

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Before this commit, if we use some client action like: reload, logout, ...
in the console a warning is show, because the action are function and not
AbstractAction.

After this commit, if the client action is not an function and not
a AbstractAction the warning is show.

X-original-commit: 122b76594aeb2c5d923d13c040c2da2048133aac

closes odoo/odoo#35404

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Rev. ee44d23 fixed a usability issue: when a doAction is performed
from a dialog, it automatically closes the dialog (as the action is
rendered in the background, behind the dialog).

However, it also closes dialogs when the action has target='new',
i.e. when it also opens in a dialog, which is not strictly
necessary in this case.

This is problematic in mobile for the product configurator widget:
in the sale.order form view, the order_line field is displayed as a
kanban, and in its form view, the product_(template_)id field has
widget product_configurator. When a value is set, it performs a
doAction (target="new") to configure the product. The widget listens
to the dialog's 'closed' event to update itself. However, with what
is done in ee44d23, the x2many form dialog is closed by the DoAction,
so the flow doesn't work.

This rev. reverts the attempt done in ee44d23, and does something a
bit more brutal: as soon as an action is pushed in target 'current'
(in the main part of the interface), all dialogs are automatically
closed.

closes odoo/odoo#34678

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>