Bug 1226661 - [engine-webadmin] Tree pane shows wrong view after browsing to 'External Providers'
Summary: [engine-webadmin] Tree pane shows wrong view after browsing to 'External Prov...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin
Version: ---
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Alexander Wels
QA Contact: Jiri Belka
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-31 14:45 UTC by Elad
Modified: 2016-02-10 19:22 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-04 11:33:57 UTC
oVirt Team: UX
Embargoed:
rule-engine: ovirt-3.6.0+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
screenshots and developer console log (259.15 KB, application/x-gzip)
2015-05-31 14:45 UTC, Elad
no flags Details
screen-cast: scenario 1 (1.23 MB, application/ogg)
2015-06-01 13:38 UTC, Einav Cohen
no flags Details
screen-cast: scenario 2 (1.45 MB, application/ogg)
2015-06-01 13:39 UTC, Einav Cohen
no flags Details
screen-cast: scenario 3 (1.36 MB, application/ogg)
2015-06-01 13:39 UTC, Einav Cohen
no flags Details
screen-cast: scenario 3 (2.10 MB, application/ogg)
2015-06-01 15:15 UTC, Einav Cohen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 42501 0 master MERGED webadmin: Make search string management intelligent 2020-09-10 12:54:03 UTC

Description Elad 2015-05-31 14:45:38 UTC
Created attachment 1032879 [details]
screenshots and developer console log

Description of problem:
After browsing to 'External Providers', and then to 'System' in the left tree pane, the shown view isn't the right one.

Version-Release number of selected component (if applicable):
ovirt-engine-3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch
ovirt-engine-webadmin-portal-3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have 2 DCs with storage domains on both
2. In the left tree pane, navigate to 'Storage' view of one of the DCs
3. In the left tree pane, navigate to 'External Providers'
4. In the left tree pane, navigate to 'System', and click on the 'Storage' tab

Actual results:
The storage domains shown are of the specific DC that was shown in step 2

Expected results:
All the system storage domains should be shown while browsing to the System view in the left tree pane.

Additional info: screenshots and developer console log

Comment 1 Einav Cohen 2015-06-01 13:38:40 UTC
Created attachment 1033353 [details]
screen-cast: scenario 1

Comment 2 Einav Cohen 2015-06-01 13:39:05 UTC
Created attachment 1033354 [details]
screen-cast: scenario 2

Comment 3 Einav Cohen 2015-06-01 13:39:27 UTC
Created attachment 1033355 [details]
screen-cast: scenario 3

Comment 4 Einav Cohen 2015-06-01 15:15:24 UTC
Created attachment 1033396 [details]
screen-cast: scenario 3

Comment 5 Einav Cohen 2015-06-01 16:28:40 UTC
it seems that we have some inconsistent behaviour after solving bug 1172389. 

the original plan was to save the last query per main-tab, but only in "System mode" (i.e. when the "System" node in the left-pane system tree is selected), and have the "Tree mode" (i.e. when any node other except "System" in the left-pane system tree is selected) completely separate and unrelated to that. 

a few scenarios to clarify: 

scenario 1 [buggy]: 
------------------
1.  [we are in "System mode"]
2.  select the 'Storage' main tab. 
3.  apply a search on this main-tab manually, e.g. "Storage: name = whatever". 
4.  [grid content is updated accordingly]
5.  select a specific Data-Center node on the System tree. 
6.  [we are now in "Tree mode". The original intent in bug 1172389 was that anything that happens in this mode should not affect the System mode's last saved query for any main tab, including the 'Storage' main-tab, i.e., the System mode's last saved query for the 'Storage' main tab should be "Storage: name = whatever".]
7.  [due to "5", the search is changed to be a disabled "Storage: datacenter = dc-name". Grid content is updated accordingly]
8.  select the "System" node. 
9.  [we are back in "System mode"]
see attachment 1033353 [details]. 

Expected Results: 
The "Storage" main-tab's search is changed to the last one *while we were on "System mode"*, i.e., "Storage: name = whatever". 

Actual Results:
The "Storage" main-tab's search is being reset to the default "Storage:". 

~~

scenario 2 [ok]: 
---------------
1.  [we are in "System mode"]
2.  select the 'Storage' main tab. 
3.  apply a search on this main-tab manually, e.g. "Storage: name = whatever"
4.  [grid content is updated accordingly]
5.  select the "External Providers" system tree node. 
6.  [we are now in "Tree mode"]
7.  [due to "5", the search is changed to be a disabled "Provider:". 'Providers' main tab becomes selected and the grid content is updated accordingly]
8.  select the "System" node. 
9.  [we are back in "System mode"]
10. [the VMs main tab is automatically selected, grid content is updated accordingly]
11. select the "Storage" main tab. 
see attachment 1033354 [details]. 

Expected and Actual Results: 
The "Storage" main-tab's search is changed to the last one *while we were on "System mode"*, i.e., "Storage: name = whatever". 

~~

scenario 3 [buggy]: 
-------------------
1.  [we are in "System mode"]
2.  select the 'Storage' main tab. 
3.  apply a search on this main-tab manually, e.g. "Storage: name = whatever". 
4.  [grid content is updated accordingly]
5.  select a specific Data-Center node in the System tree. 
6.  [we are now in "Tree mode"]
7.  [due to "5", the search is changed to be a disabled "Storage: datacenter = dc-name". The grid content is updated accordingly]
8.  select the "External Providers" system tree node. 
9.  [we are still in "Tree mode"]
10. [due to "8", the search is changed to be a disabled "Provider:". 'Providers' main tab becomes selected and the grid content is updated accordingly]
11. select the "System" node. 
12. [we are back in "System mode"]
13. [the VMs main tab is automatically selected, grid content is updated accordingly]
14. select the "Storage" main tab. 
see attachment 1033396 [details]. 

Expected Results: 
The "Storage" main-tab's search is changed to the last one *while we were on "System mode"*, i.e., "Storage: name = whatever". 

Actual Results:
The "Storage" main-tab's search is changed to the last one *while we were on "Tree mode"*, i.e. "Storage: datacenter = dc-name".  

~~

So it seems that when moving from "Tree mode" back to "System mode", the search will either:
a. reset to the default one (scenario 1), or: 
b. change to the last one *while we were on "System mode"* (scenario 2), or: 
c. change to the last one *while we were on "Tree mode"* (scenario 3). 

This behaviour is inconsistent. 

The preferred behaviour:
i.   apply "b" / results of scenario 2 across all possible scenarios (this was my original intent in bug 1172389), but I am not sure if it is easy to achieve. 

Other improved behaviours (though not optimal, in my view, but may be easier to implement) may be:

ii.  applying "a" all over, i.e., always reset to the default search when moving from "Tree mode" to "System mode". 

iii. sort-of a combination between "b" and "c": When moving from "Tree mode" to "System mode", change the search to the last one, *no matter which mode we were at that last one*. 
So the actual results of scenario 2 are ok, and so are the actual results of scenario 3 if we are choosing to implement this improved behaviour. 
[In scenario 2, the Storage last saved query will happen to be a "System mode" one; in scenario 3, the Storage last saved query will happen to be a "Tree mode" one - but they both qualify as "the last 'Storage' query"]. 
The expected results of scenario 1 would have to change though - the search would need to change to "Storage: datacenter = dc-name" (actually remain as is - just changed to be enabled), which is the last 'Storage' search in this scenario (which happens to be a "Tree mode" one). 


@Alexander - 
Any thoughts on the above? 
Any estimation on what would be easiest to implement / would involve the least risk for regressions / unexpected behaviours (i/ii/iii)? 
Any suggestions for other types of improvements?

Comment 6 Alexander Wels 2015-06-15 18:45:26 UTC
Let me explain what happens in all the different scenarios, including the 'bug' reported originally.

Original bug:
1. User selects the storage tab, and the search string of the storage model is set to the default search string (aka nothing specific) by the common model, which constrols the contents of the search string.
2. User clicks on a specific data centers storage in the tree, the tree instructs the storage model to search only on the specific data center that is clicked on. This sets the search string through the common model.
3. User clicks on the provider tab, which changes the search string on the provider model, but doesn't touch the storage model.
4. User clicks on the system tree, due to some logic the VM tab is displayed (it can't display the provider tab as its not part of the list of available tabs for when the system node is selected.
5. User clicks on the storage tab. And sees the storage search string since that is the behavior defined by the fix for bug 1172389. Before the search string would be reset to the default, instead of keeping the current value. Since the storage (or any other model for that matter) doesn't know that there are specific types of search strings (like the tree vs system model described above). It thinks it is doing the right thing by displaying the last search.

The 3 scenarios described by Einav are all just slight variations of the same thing. Except that she manually sets the search string before it gets changed by clicking a specific storage in the system tree.

To me the real 'bug' is that that clicking from a specific storage to the system directly properly clears out the search string vs click on the providers first doesn't properly clear out search string. So you get the scenario where you click a specific storage, that sets the search string, then click the provider, which doesn't affect the search string, then you click system which causes a change to the default VM tab, and then click the storage tab, which now has the saved search string (the one that was put in place by clicking a specific storage item in the tree).

So we have a few options to consider:
1. We decide that clicking from any items in the system tree that don't have an associated tab in 'system' mode. Should clear all models search strings.
2. We decided that clearing the search string at all when clicking from any item in system tree to the 'system' mode is a bug and stop doing that for consistent behavior. This will cause clicking between system and a specific storage and back again, to keep the search string put in place by clicking a specific item.
3. Implement some sort of history mechanism in the controller of the tree (common model in our case). That keeps track of what the user does in which part of the tree and intelligently decides what search string to put based on which tree node is selected.
4. Keep it as is, as all the things it is doing right now are logic.

@Einav,
Let me know which option you want to go with.

Comment 7 Einav Cohen 2015-06-15 20:32:19 UTC
my preferred solution is (i) on comment #5. to my understanding, this will require to persist for each main-tab-list-model something like "last-query-in-system-mode", which will be updated if the user changes the main tab's query only while in system mode (typically via manually altering the search text); so when going into 'tree mode', this value will not be changed or cleared, for any reason. and when going back to 'system-mode' - the persisted "last-query-in-system-mode" of the relevant main-tab will be applied. 

if this is too large/risky of a change, we can go with your solution 2, which I think is similar to my solution (iii) - always save history, and never clear it: persist for each main-tab-list-model something like "last-query" which will be updated upon every change to the main-tab's search query (no matter if in system-mode or tree-mode). 

No matter which solution we are choosing - the saved-query will be applied in the GUI *only in system-mode* (in tree-mode, the applied search-query should be the one reflecting the relevant tree-node selection, regardless of the last-query persisted, and for the second solution - even overriding it). 

@Alexander - thoughts?

Comment 8 Alexander Wels 2015-06-17 15:27:07 UTC
Should be possible, pushing patch soon.

Comment 9 Max Kovgan 2015-06-28 14:12:01 UTC
ovirt-3.6.0-3 release

Comment 10 Jiri Belka 2015-10-15 09:07:44 UTC
ok, rhevm-webadmin-portal-3.6.0-0.18.el6.noarch

testing based on #c0 and #c5 (scenario 2).

Comment 11 Sandro Bonazzola 2015-11-04 11:33:57 UTC
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.


Note You need to log in before you can comment on or make changes to this bug.