public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Philipp Hufnagl <p.hufnagl@proxmox.com>,
	Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] applied: [PATCH manager v4 0/2] fix #474: allow transfer from container/vms
Date: Wed, 30 Aug 2023 16:29:48 +0200	[thread overview]
Message-ID: <027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com> (raw)
In-Reply-To: <ee6dfaf8-5d05-44ff-b2c6-56616d2435c0@proxmox.com>

On 8/30/23 14:43, Philipp Hufnagl wrote:
> On 8/14/23 12:42, Dominik Csapak wrote:
> 
>> On 8/14/23 12:36, Wolfgang Bumiller wrote:
>>> applied, thanks
>>>
>>> @Dominik: does extjs have an 'enableFn' for rows in a grid?
>>> IMO we should either disable the ones with pools when the transfer
>>> checkbox is not checked, or hide them (but when hiding them after
>>> already checking them... it's weird)
>>> Or disable the 'Add' button if a VM with a pool is checked?
>>>
>>
>> 'enableFn' is our invention ;) and no that only works for some of our components
>>
>>
>> looking just now at the gui patch, i would have approached it a bit differently:
>>
>> always enable the 'transfer' property but show a 'warning' box when one is selected
>> with an old pool
>>
>> since 'Allow Transfer' is rather non-descriptive (and no documentation is included)
>> and it adds needless friction on change
>> (i select a vm, click, get an error, have to select the vm again, click transfer, click button..)
>>
>> also there is some whitespace error (missing space between && and 'item.data.poll')
>> don't know why eslint did not pick that up...
> 
> 
> I considered the option of a warning box. I decided against it because I thought it too verbose 
> throwing a warning box every time the user wants to transfer/migrate.
> 

IMHO that contradicts itself, since now the user has to press a checkbox more than just read a 
warning. So with a warning, the user has *less* things to do than with the checkbox.
(just read, no clicking; users that know the warning will not read it anyway)

a warning per line would be even nicer, so that the user sees at once which vms are affected.

> As for the UI I agree that it could be improved. Would it solve it if the vms currently part of a 
> pool are only shown AFTER the check box is checked? This way the User could never experience this 
> error.
> 
> 

I don't think that's good because now the user has to either know beforehand it's in another pool,
or search the whole list, wondering where the vm is, just to click the checkbox and search again?

In general we try to make the UI as easy to use as possible, without having to impose too many
hurdles (except the action has severe consequences like deleting data!) but show appropriate
warnings when things might be unexpected (like here with the transferring of one pool to another,
since a user might expect that the vm is in both pools afterwards)





  reply	other threads:[~2023-08-30 14:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 10:09 [pve-devel] " Philipp Hufnagl
2023-08-10 10:09 ` [pve-devel] [PATCH manager v4 1/2] fix #474: api: " Philipp Hufnagl
2023-08-10 10:09 ` [pve-devel] [PATCH manager v4 2/2] fix #474: ui: " Philipp Hufnagl
2023-08-14 10:36 ` [pve-devel] applied: [PATCH manager v4 0/2] fix #474: " Wolfgang Bumiller
2023-08-14 10:42   ` Dominik Csapak
2023-08-24 14:46     ` Thomas Lamprecht
2023-08-30 12:53       ` Philipp Hufnagl
2023-08-31 13:47         ` Thomas Lamprecht
2023-08-30 12:43     ` Philipp Hufnagl
2023-08-30 14:29       ` Dominik Csapak [this message]
2023-08-31  8:08         ` Philipp Hufnagl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=p.hufnagl@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=w.bumiller@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal