Bug 1124580 - Missing title (or icon) for column 4 (vms?) in Disks tab
Summary: Missing title (or icon) for column 4 (vms?) in Disks tab
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin
Version: ---
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.0.0-alpha
: ---
Assignee: Tal Nisan
QA Contact: Aharon Canan
URL:
Whiteboard:
Depends On:
Blocks: 1140093
TreeView+ depends on / blocked
 
Reported: 2014-07-29 20:40 UTC by Nir Soffer
Modified: 2016-03-10 11:58 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-10 11:58:29 UTC
oVirt Team: Storage
ylavi: ovirt-4.0.0?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)
Screenshot showing the missing title (39.27 KB, image/png)
2014-07-29 20:41 UTC, Nir Soffer
no flags Details
mockup: proposed "Attached To" column (76.94 KB, image/png)
2014-08-18 18:42 UTC, Einav Cohen
no flags Details
attach_to icon undefined (301.03 KB, image/jpeg)
2014-08-19 12:09 UTC, Eldan Hildesheim
no flags Details

Description Nir Soffer 2014-07-29 20:40:58 UTC
Description of problem:

Column 4 of Disks tab has no title. According to the content, it should us the vm icon seen in some of the rows.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.5.0-0.0.master.20140722232056.git8e1babc.fc19

Should be trivial fix.

Comment 1 Nir Soffer 2014-07-29 20:41:40 UTC
Created attachment 922340 [details]
Screenshot showing the missing title

Comment 2 Daniel Erez 2014-07-30 18:29:26 UTC
This behavior is actually by design, an image column with multiple possible icons usually has an empty title (e.g. any status column or desktop/server column in VMs main-tab). In order to resolve it, we should consult UX designers whether a single icon, that represents all possibilities (VM/Template/none), can be provided.

Comment 3 Liz 2014-08-18 18:39:55 UTC
From a UX perspective, I think one possibility would be to combine the column headers for the icon and the "Attached To" column. This would make the field just one column. We could then append the icon to the beginning of the "Attached To" column so that it would read the exact same way it does today, but it would also get rid of the issue seen in the screenshot. In this case, it would just show two blank fields under the "Attached To" column.

Thoughts on this approach?

Thanks,
Liz

Comment 4 Einav Cohen 2014-08-18 18:42:38 UTC
Created attachment 928029 [details]
mockup: proposed "Attached To" column

Comment 5 Allon Mureinik 2014-08-18 20:24:42 UTC
Sounds good to me. Tal/Daniel - is this feasible from a GWT perspective?

Comment 6 Tal Nisan 2014-08-19 10:16:27 UTC
Sounds feasible to me, Daniel, your thoughts?

Comment 7 Daniel Erez 2014-08-19 10:39:06 UTC
(In reply to Tal Nisan from comment #6)
> Sounds feasible to me, Daniel, your thoughts?

I don't recall any similar column but probably should be done using 'CommonApplicationTemplates -> iconWithTextAndTitle' on DiskContainersColumn.
Though might be worth creating a generic column in the UI infrastructure for that (unless we don't plan reusing this concept...)

Comment 8 Eldan Hildesheim 2014-08-19 12:07:58 UTC
I'm fine with the solution as well.
Small thoughts: In the near future we would like to have sorting to each column.
I am not sure that here is the case of sorting once by the: attach to type column and once by the: attach to name.
But Anyway I am adding the mockup of an icon which is blur, meaning the parent is not defined.

Comment 9 Eldan Hildesheim 2014-08-19 12:09:21 UTC
Created attachment 928337 [details]
attach_to icon undefined

Comment 10 Allon Mureinik 2014-08-27 16:43:16 UTC
This is an (old) GUI nit - should be fixed, but should not block 3.5.0 - pushing out to 3.5.1.

Comment 11 Red Hat Bugzilla Rules Engine 2015-10-19 10:49:29 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 12 Yaniv Lavi 2015-10-29 12:06:04 UTC
In oVirt testing is done on single stream by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.

Comment 13 Yaniv Lavi 2015-11-02 12:37:21 UTC
What browser are you using? Can you still see this issue?

Comment 14 Nir Soffer 2015-11-02 13:02:44 UTC
(In reply to Yaniv Dary from comment #13)
> What browser are you using? Can you still see this issue?

I'm using chrome, don't know it this still exist.

Comment 15 Yaniv Lavi 2015-11-02 13:25:15 UTC
Can you check? can you make sure you are not zoomed?

Comment 16 Nir Soffer 2015-11-09 17:35:07 UTC
(In reply to Yaniv Dary from comment #15)
> Can you check? 

The issue still exits, tested on Chrome
Version 46.0.2490.71 (64-bit)

> can you make sure you are not zoomed?

I don't know what do you mean by "zoomed".

Comment 17 Eldan Hildesheim 2015-11-10 12:28:56 UTC
he means that your browser is set on zoom that is higher than 100%.
Normally it should be 100% (go to chrome > view > actual size)

Comment 18 Nir Soffer 2015-11-20 12:12:09 UTC
(In reply to Eldan Hildesheim from comment #17)
> he means that your browser is set on zoom that is higher than 100%.
> Normally it should be 100% (go to chrome > view > actual size)

No, I'm using 100% zoom, but I'm using custom font settings:

Standard font: 18
Serif font: 18
San-serif font: 18
Fixed-width font: 18
Minimum font size: 14

This settings is needed to mitigate unusable small fonts used by
lot of sites, instead of using 100% font size, respecting my
font preferences.

Comment 19 Yaniv Kaul 2016-03-10 11:25:58 UTC
Any chance of fixing it for 4.0, or just CLOSE-WONTFIX?


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