public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Philipp Hufnagl <p.hufnagl@proxmox.com>
To: Dominik Csapak <d.csapak@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: Thu, 31 Aug 2023 10:08:15 +0200	[thread overview]
Message-ID: <b6341e93-4a8a-4a0d-80bf-2182b9bade90@proxmox.com> (raw)
In-Reply-To: <027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com>

On 8/30/23 16:29, Dominik Csapak wrote:
> 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)
>
>
I misunderstood you before. Having a simple notification appear the way 
you descriped sounds like a good solution too. I will make a patch 
featuring that




      reply	other threads:[~2023-08-31  8:08 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
2023-08-31  8:08         ` Philipp Hufnagl [this message]

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=b6341e93-4a8a-4a0d-80bf-2182b9bade90@proxmox.com \
    --to=p.hufnagl@proxmox.com \
    --cc=d.csapak@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