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 908CD8404 for ; Wed, 30 Aug 2023 16:29:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 70F21360EC for ; Wed, 30 Aug 2023 16:29:50 +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 ; Wed, 30 Aug 2023 16:29:49 +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 84ED04778B; Wed, 30 Aug 2023 16:29:49 +0200 (CEST) Message-ID: <027d79fb-8fe6-415f-b1df-a7014bbde1b8@proxmox.com> Date: Wed, 30 Aug 2023 16:29:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Philipp Hufnagl , Wolfgang Bumiller Cc: pve-devel@lists.proxmox.com References: <20230810100902.714456-1-p.hufnagl@proxmox.com> <119c8829-8f7a-4269-9436-b39e9242dece@proxmox.com> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.011 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: Wed, 30 Aug 2023 14:29:50 -0000 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)