Bug 1434048

It's by design in Patternfly. See http://www.patternfly.org/pattern-library/communication/wizard/#/code for an example.

However, I'll bring it up with the Patternfly team and report back.

@Michael,

What problem is being caused by not being able to drag the window. Maybe we can mitigate the issue or even get something better there.

(In reply to Alexander Wels from comment #2)
> @Michael,
> 
> What problem is being caused by not being able to drag the window. Maybe we
> can mitigate the issue or even get something better there.

Hi Alexander

Not being able to drag and move the window doesn't causing a problem, but, from my perspective it's really great benefit to our product and to the user experience in general.

I'm using it quite a lot trough all previous versions on my daily basis, and i find it very useful, as i'm one of those 5% who find this very helpful to do my work and tasks(yes, i doing multitasking a lot) and i need sometimes the info hidden under the window.

I understand this is the new design in Patternfly and it should help the user/admin completing the task, but for me it is a regression and quite annoying that i'm not able to drag the windows any more. 
I found some qe stuff feel this way as well. 

I'm not sure what harm it can do if we will allow it as it was on all previous versions of rhv-m. 

We have a thread running in the e-mail about this and every decision will be great, this is just my point of view, as i'm using this a lot on my work.

Some use cases: 

1) When creating a new VM on a large rhv-m production environment with a lot of DCs, clusters and VMs, like we have(rhevm-3 for qe and dev). 
Almost every time that i need to create a new VM on this environment, i'm moving the new VM dialog bit a side, because it's hiding a reference to the desired DC/Cluster which my other VMs are running on.
When i move the dialog, i know exactly on which cluster and DC to create it, without the need to cancel.

2) Create new network with vlan, but vlan is in use, i can drag the new/edit network window and to look which vlan isn't in use.
This is relevant as well for which network has specific label, QoS and role. Sometimes you need the info of other networks while creating new network and you don't always would like to cancel to view this info.  

3) New data domain, one created with nfs type and one with iscsi, not always recall what was created first, the iscsi? nfs? can drag the window and take a look on what i already added. 

4) New cluster, you need a reference of a Cluster CPU type of a specific cluster in a large list of clusters. 

Note, that most of the real use cases are in large setups, with a lot of DCs, clusters, networks, hosts, data domains, VMs and so on..
I'm sure that we can find more use cases if we will ask the whole rhv qe stuff.

- The more i ask around the qe stuff , i understand that a lot of us using this window dragging on a daily/weekly basis. And each team with it's real need for information.  

- Some of the info that is required, not always could be possible on the window dialog itself and hidden behind it, but it could be helpful to complete the task.

Another real use case is to provide a good and complete information by one screenshot.

Attaching some for examples - 

When you have a multiple dialog windows hiding each other, i can move them a bit and provide full info by one screenshot, that can tell the whole story(i sue it from time to time). 

- Some examples:
1) Edit network in the setup networks dialog - screenshot 1

2) Edit disk on edit VM dialog - screenshot 2

Created attachment 1265392 [details]
screenshots

We'll consider that for 4.2.
It will either be fixed, or closed. See latest discussions. If closed, you'll probably want to open issues on the specific data in the dialogs themselves.

Verified on - 4.2.0-0.0.master.20170723141021.git463826a.el7.centos

It is possible to drag every dialog.

This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.