FW-Port of odoo/odoo#70675 (13.0) closes odoo/odoo#70728 X-original-commit: 85c24961ab9ff5c1c79eb7415c97c46d9a77cca3 Related: odoo/enterprise#18283 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In eg. 13.0 when refreshing sales analysis action of a product, we would get an error because we have a single active_ids which is not expected by the code. With this commit, we use .toString() on the jQuery BBQ parsed active_ids as it was done before 32b8cec5 refactoring (january 2018). The added test with the fix fails with an error: TypeError: state.active_ids.split is not a function at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js) opw-2471982 closes odoo/odoo#70279 X-original-commit: bf9a985f4b62cc6f1eef4f9fcca2a8dfbd453004 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com> Co-authored-by: Nicolas Lempereur <nle@odoo.com>
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-L46
closes odoo/odoo#69962
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
before this commit: when there is a horizontal scroll in view say for example kanban view where there are too many columns and user scrolls horizontally and go to form view by clicking on any record and then come back to kanban view horizontal scroll is not preserved and user is moved to scroll position 0 this is due to commit: https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242 after this commit: scrolling horizontally and then go to form view and come back to previous view will preserve scroll position, we also consider case for kanban view where there are too many columns and user click on 'Add Column' user will be scrolled to new column element. task-2418275 closes odoo/odoo#66218 X-original-commit: 171036aefe21799f7a791cc3cd73a7d249aa0b00 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
- Create 2 companies A & B - Set a website on company A - Switch to company B - Open a done MO - Open the cost analysis An AccessError is displayed. The error arises in: https://github.com/odoo/enterprise/blob/923cbffe4e60572a5c17ee962d571c037e9cff44/mrp_account_enterprise/reports/mrp_cost_structure.py#L90 The root cause is coming from the call to `/report/html/`, which is called without any `data`. In this situation, the following adds an incorrect `allowed_company_ids` in the context: https://github.com/odoo/odoo/blob/d1413a2f06bcb44b1fbb6dba8658e698c8da4018/addons/website/models/ir_http.py#L196-L205 Indeed, the `allowed_company_ids` is the one from the website, in this case company A. The issue doesn't occur when downloading a PDF from the interface since in this case the `data` dictionary contains the appropriate context which is set in: https://github.com/odoo/odoo/blob/d1413a2f06bcb44b1fbb6dba8658e698c8da4018/addons/web/controllers/main.py#L1958 As a solution, we add the `user_context` in the `/report/html` route. opw-2341747 closes odoo/odoo#59654 X-original-commit: 932e347a90bfd4bf025e4e8e54ef9c66cc49c5d0 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit aims at fixing a random bug on the runbot. When loading the webclient, if there is no hash, a rpc is done to read the default action of the user. When this rpc comes back, we execute the given action (if any), or the first action (typically Discuss). The navbar is displayed as soon as possible, it doesn't wait for the first action to be executed. This means that the user can open the user menu and click on 'My Profile' before the first action is executed. Before this commit, if the user clicked before the read rpc on 'res.users' returned, the default action (or the first) one, was executed, even though the user clicked on 'My Profile' and thus asked for a specific action. So basically, the user form view was briefly shown, and then replaced by the default or first action. Whereas this is a very rare usecase in practice (the timing is really short), this sometimes made the totp tour fail. However, even if it is unlikely, the client must be robust and correctly react to concurrent requests. This commit fixes the issue by executing the 'My Profile' action in the DropPrevious. That way, if any 'doAction' is performed, other pending operations (also done in DropPrevious) are dropped. This commit also ensures that the "brand name" part in the navbar (containing the name of the current app) is hidden when there is no current app, as in the scenario described above, we land in a webclient with no current app. Note that not being in an app was something that was already handled, but not at startup. closes odoo/odoo#57840 Related: odoo/enterprise#13277 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit handles two things: 1) Move the local storage logic of the search panel into the documents module. 2) This allows for a variety of optimisations now that we do not have to constantly wait for a potential default value hidden in the storage. This is why this commit also introduces a way for the search panel model extension to sometimes return its query informations sooner than after being completely loaded. Task 2284207
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>
Adaptation of the rest of the environment to the changes regarding the refactored search panel and model. This commit includes the following changes: - Since the control panel model is now part of the search model, the view widget is responsible of its instantiation with the appropriate API; creating an ActionModel holding the required model extensions. - The controller is now importing/exporting the state of the entire search model as well as the current state of the search panel (given throught its props). Changes have been made to adapt to this behaviour. - The multiple components linked to the control panel model have been adapted to reflect the changes brought to it (they will now listen to the "searchModel" instead of the "controlPanelModel"). - The `test_utils_create` methods have also been adapted to properly instantiate a searchModel Part of task 2228968 Co-authored-by: Julien Mougenot <jum@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>