Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1057141 - [RFE] UI: When focusing on a child node of the system tree, bookmarks can not be edited or removed
Summary: [RFE] UI: When focusing on a child node of the system tree, bookmarks can not...
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-webadmin
Version: 3.4
Hardware: All
OS: Linux
Target Milestone: ---
: ---
QA Contact:
Whiteboard: ux
Depends On:
TreeView+ depends on / blocked
Reported: 2014-01-23 14:04 UTC by Gil Klein
Modified: 2015-04-02 08:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2015-04-02 08:57:53 UTC
oVirt Team: ---

Attachments (Terms of Use)
Grayed out bookmark options (deleted)
2014-01-23 14:04 UTC, Gil Klein
no flags Details
screen-shot: a seemingly-selected bookmark vs. an actually selected bookmark (deleted)
2014-01-24 15:02 UTC, Einav Cohen
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1059646 None None None Never

Internal Links: 1059646

Description Gil Klein 2014-01-23 14:04:34 UTC
Created attachment 854407 [details]
Grayed out bookmark options

Description of problem:

When focusing on a child node of the system tree, bookmarks option are grayed out, and can not be removed or edited.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Add a new bookmark from the search bar
2. Go to the System tree 
3. Click "Data centers" 
4. Click the "Bookmarks" tab
5. Right click the bookmark you have just created

Actual results:
Edit and Remove options will be grayed out 

Expected results:
Edit and Remove options should be operational

Additional info:

Comment 1 Einav Cohen 2014-01-24 15:02:00 UTC
Created attachment 855001 [details]
screen-shot: a seemingly-selected bookmark vs. an actually selected bookmark

Comment 2 Einav Cohen 2014-01-24 15:24:28 UTC
this is actually not entirely related to being focused on a child node of the system tree (although the problem is indeed more painful in that case): 

currently, we don't have a way of editing a bookmark without selecting it. 
i.e., today, if you want to edit a bookmark, you must select it first. 
this is wrong, since selecting a bookmark applies that bookmark on the application, and the user doesn't necessarily wants to do that, so we need to find a solution for that. 

[specifically, when a child node is selected on the System tree, the bookmarks are disabled (by design, IIRC), so you cannot actually select them, therefore you cannot edit/remove them at all in this context, which makes the problem described above even more "painful"]

another problem that we have is that the GUI is misleading - see attachment 855001 [details]: when you are right-clicking a bookmark, the bookmark's background becomes yellow, which implies that it is selected in some level, so the user may expect that the displayed context-menu will be shown in the context of this seemingly-selected item (allowing Edit and Remove of this item, for example);  however - this is not the case: the item is actually not selected at all, and the context menu is indeed displayed in an "empty" context (i.e. only the "New" action is available from it). 

In my opinion, we should do the following:

(1) find a way of editing a bookmark without applying that bookmark to the application (maybe we can fix the behavior so that a bookmark that is being right-clicked and colored yellow will actually be selected for edit/remove purposes, but will not be applied to the application - may be tricky to implement though; we can also consider an entirely new concept). 

(2) IMO, we need to enable applying bookmarks even if we are focused on one of the System tree's child nodes (even if it means temporarily selecting the "System" root tree-node "behind the scenes" once going to the "Bookmarks" section, and returning to the last-selected-by-user tree-node when returning to the "System" section). 

'needinfo'ing Eldan/Malini for their thoughts.

Comment 3 Eldan Hildesheim 2014-01-26 13:00:04 UTC
Agree with Einav on both issues.
I think the main problem is that the bookmarks are selected and not just clicked.
What I mean is when a bookmark is clicked, it stays selected.
Same for the tree's nodes: when a node is selected it stays selected.
But we can only have 1 selected (blue background) entity over the bookmark/tree area.

Bookmarks should be treated as "simple buttons" - you click a bookmark and it doesn't stays selected, in that way, we could get what Einav proposed in her 2nd issue:
-You are focused on a tree node and can still click a bookmark.

And the problem of remove/edit a bookmark is solved since there is no significance to a selected bookmark.

Comment 4 Eldan Hildesheim 2014-02-02 12:27:09 UTC
Bug 1059646 will be solved as well according to the proposed solution.

Comment 5 Itamar Heim 2015-03-29 09:06:16 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Comment 6 Pavel Stehlik 2015-04-01 12:34:20 UTC
This issue still stands. bug 1059646 was fixed, can we fix also this one? (maybe in next release?).

Comment 7 Einav Cohen 2015-04-01 16:13:10 UTC
(In reply to Pavel Stehlik from comment #6)
> This issue still stands. bug 1059646 was fixed, can we fix also this one?
> (maybe in next release?).

bug 1059646 (or, bug 1052151) was resolved by making sure that when we are focusing on the "Bookmarks" section, the "System" (root) tree-node in the System tree gets automatically selected. 

so I consider this BZ to be resolved: when selecting a non-"System" tree-node in the system tree, and focusing on the Bookmarks section - bookmarks editing are now enabled. 
however (as sort-of a "release note"), after the user is done with editing the Bookmarks and going back to the "System" tree, the tree will have the "System (root) node selected, and not the last-selected (non-"System") node as he may expect. 

I am not sure if pursuing a solution for the "release note" above is worth the effort - I am not sure how popular of a use-case it is, and we are planning to eliminate the System tree altogether for 4.0 anyway. 

Therefore, I recommend to close this bug. 

If you have any questions or comments that require any additional feedback from me - please feel free to 'needinfo' me again. 


Comment 8 Pavel Stehlik 2015-04-02 08:57:53 UTC
As per c#7 explanation - 4.0 should solve this issue.

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