From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7C4098652 for ; Thu, 31 Aug 2023 10:08:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 662446ABC for ; Thu, 31 Aug 2023 10:08:17 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 31 Aug 2023 10:08:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D0835478CF for ; Thu, 31 Aug 2023 10:08:15 +0200 (CEST) Message-ID: Date: Thu, 31 Aug 2023 10:08:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Dominik Csapak , Wolfgang Bumiller Cc: pve-devel@lists.proxmox.com References: <20230810100902.714456-1-p.hufnagl@proxmox.com> <119c8829-8f7a-4269-9436-b39e9242dece@proxmox.com> <027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com> From: Philipp Hufnagl In-Reply-To: <027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.004 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] applied: [PATCH manager v4 0/2] fix #474: allow transfer from container/vms X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2023 08:08:17 -0000 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