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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id EAA447123D for ; Tue, 18 May 2021 09:01:09 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E0D15BCA3 for ; Tue, 18 May 2021 09:00:39 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 61C75BC94 for ; Tue, 18 May 2021 09:00:39 +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 2BD6F465CB for ; Tue, 18 May 2021 09:00:33 +0200 (CEST) Message-ID: <2e2480a1-1c71-2a53-6a38-1b7a39c17a02@proxmox.com> Date: Tue, 18 May 2021 09:00:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Proxmox Backup Server development discussion , Dominik Csapak References: <20210514125923.14955-1-d.csapak@proxmox.com> <20210514125923.14955-5-d.csapak@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20210514125923.14955-5-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.006 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup v2 4/5] ui: tape/window/TapeRestore: enabling selecting multiple snapshots X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 07:01:10 -0000 On 14.05.21 14:59, Dominik Csapak wrote: > by including the new snapshotselector. If a whole media-set is to be > restored, select all snapshots > > to achieve this, we drop the 'restoreid' and 'datastores' properties > for the restore window, and replace them by a 'prefilter' object > (with 'store' and 'snapshot' properties) > > to be able to show the snapshots, we now have to always load the > content of that media-set, so drop the short-circuit if we have > the datastores already. > > also to improve space-usage, shift the datastores mapping grid in the > right column, and all non datastore related options in the left one, > showing the snapshot grid below > (the datastore mapping is now limited to 150px; ~3 datastores, and scrollable) > > Signed-off-by: Dominik Csapak > --- > www/tape/BackupOverview.js | 27 +++------- > www/tape/window/TapeRestore.js | 99 ++++++++++++++++++---------------- > 2 files changed, 61 insertions(+), 65 deletions(-) > I tried it now a bit, also with multi-datastores, I found one thing quite confusing: 1. restore whole mediaset with multiple datastore 2. set mapping for only one datastore and no default datastore -> the snapshots on other datastore are still selected, but for the user this is highly confusing, as they cannot know about what will happen to them? Not restored, used in the same mapping, .. Deselection of those snapshots without a datastore-map is not an option, as the next datastore-mapping could be still configured immediately after setting the first one. IIRC, you mentioned the idea of a multi-step wizard, that could solve this here more nicely. I'd do two steps: 1. Show "Media Set" and "Media Set UUID" at the top, then only the snapshot grid below 2. Now we know all possible datastores from the selected snapshot list, so the datastore-map-grid can be filtered to only show relevant ones. The drive could go in either step, at least wouldn't be completely off. That would separate the "what do I need to restore" from the "where do I want to put it" a bit and two simpler sequential panels are probably easier to grasp for a user than one rather complex one. What do you think?