| Age | Commit message (Collapse) | Author |
|---|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
There used to be no processing done at all when loading the client
from an url missing a menu_id and from which the menu could not
be inferred from the action_id. This resulted in the app name
button in the menu being empty but still present and not bound to
any action. Clicking on it triggered a traceback.
This commit stops ignoring the case when the menu cannot be
inferred from the action and hides the entire menu and submenus
for this particular action. They will be restored when entering
an action from which a proper menu can be inferred.
closes odoo/odoo#27791
|
|
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
|
|
Before this rev., there was a race condition making some tours
randomly fail on runbot, when the following steps occurred in that
order:
- load webclient
- as soon as the menu is ready and visible, click on a root menu
which thus leads to a doAction
- in the meantime, an RPC is done by the webclient to retrieve
the (optional) default action of the user (if there is no
state in the url, which is the case for tours in general)
- when that RPC returns, this action (if any), or the action of
the first menu is executed, thus leading to a second doAction
- the ActionManager using a DropPrevious, the first doAction is
dropped and thus the action linked to the clicked menu is
never shown, making the tour fail
This rev. uses the state of the ActionManager's DropPrevious to
prevent the default action from being executed if another action
is already being executed, thus removing that race condition.
Note that this fix is temporary, as the community webclient is
currently being refactored.
|
|
Since 6dc37ee461c9 a d-none class was added to hide the menus in the
navbar during the start of the navbar. A timeout was set to mimic the
old behavior and let enought time to bind events on menus.
When the project app was installed alongside with all other apps on the
runbot, there was not enough place in the navbar. This resulted in a
race condition at the begining of the project tour.
With this commit, the d-none class is immediately removed and then the
menu are started (binded to events) before the tour has the hand to
continue its next step.
|
|
* portal, web_tour, website, base
Before this commit, there were 3 different implementations for the same
feature: the "more" button in the community navbar, the "+" button for
the website menu and the "+" button in the enterprise navbar. As those
implementation were now broken with BS4, it was a good time to share the
code of those 3 features.
|
|
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
|
|
|
|
before this fix, hitting the ALT key did not show the shortcuts on the
buttons
after this fix, the events of the web_client are extending those of
abstract_web_clients where the keyboard navigation is hooked up, so the
shortcuts are visible
|
|
Here is a scenario that could happen before this commit:
1. web client is started
2. it binds a callback on hashchange
3. it performs some async work (read initial action for user)
4. the user (or more likely, a tour) changes the url
5. the hashchange handler is called, and it starts a new action
6. the async work for the web client is over, it then executes the
default action and/or clicks on the first menu
7. we are now in the default action state, instead of the desired action
state (the one from the new url)
With this fix, we simply do nothing when there was an hashchange before
the initial action was done.
|
|
|
|
|
|
Before this commit, we had the following issue:
1. install CRM and Sales
2. Sales > Customers > (open any form)
3. Click on browser's "back" button
We are redirected to the contact kanban view in CRM
instead of Sales.
This is due to the fact that both menu items share the
same action. When the user uses the browser's "back" button
(AKA. it triggers an hashchange event), the web_client opens
the first menu_item that matches the action.
This commit fixes the issue by allowing us to open an action
by providing a menu ID:
1. If it matches the action, then it opens this menu
instead of the first match.
2. If we do not provide any menuID, or this menuID does
not match with the action, it falls back to the first
menu matching this action.
Fixes #23639
|
|
Before this commit, the menu_id displayed in the url was incorrect
when we click on a menu item for the first time.
This is due to the fact that the web_client was mistakenly using the
previous menu_id as the action's menu_id: the JS widget menu is not
up-to-date with the value of the current menuID, and the web client
was relying on its internal state instead of the server's response.
With this commit, the web client uses the server's reponse to
register the correct menuID that has been clicked.
|
|
This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):
- generalize the scroll position handling from web_enterprise to
web to make it available in the community webclient as well
- also restore left scroll position, not only top (especially
useful for grouped Kanban views with a lot of columns)
- handle the case where the scrolling area is a sub element of
the view (e.g. the grouped Kanban view in mobile).
Task 34037
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
|
|
This commit only concerns the community webclient. The user can
edit the company data by clicking on the company logo displayed
in the submenu (left bar). When it does, the logo's url must be
updated to force the logo to be reloaded.
The last part doesn't work since the new views, as it uses an
hook of the form view (called when it is saved) that doesn't
exist anymore.
This rev. adapts the code so that the logo is reloaded when the
edit menu dialog is closed.
It also ensures that the logo is properly reloaded by specifying
the timestamp in the img url as a query string parameter instead of
an hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
|
|
Before this rev., a traceback was raised when the user tried to
edit the company data, by clicking on the company logo in the
submenu (community edition only). This was due to code not being
converted after the ActionManager refactoring of 7b6056a0.
Also ensures that the logo is properly reloaded by specifying the
timestamp in the img url as a query string parameter instead of an
hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
|
|
Before this rev., on_attach_callback of the ActionManager wasn't
called at init, because the WebClient didn't use the append
function of dom_utils.
|
|
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
|
|
|
|
The RPC system was not completely satisfactory, we decided to prepare
the future and do it properly. This commit introduces the new rpc
system, which replace the previous new one. We now simply have a
method, this._rpc, which takes a dictionary of parameters. The idea is
that depending on the parameters, it is able to add correct default
value when necessary.
For situations where we don't have the this._rpc method, we can use the
rpc.query method, which takes the same arguments, but directly calls
ajax.rpc instead of triggering up some events.
|
|
The _rpc method is now the preferred method to do a rpc, so we need to
update all calls.
|
|
Use this.rpc instead of Model object, with web.ajax if necessary.
nb: EventDispatcherMixin include now the custom_events managment instead
of widget
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
