From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
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 4408491094
for <pve-devel@lists.proxmox.com>; Fri, 26 Jan 2024 14:27:45 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 2A4E135E2E
for <pve-devel@lists.proxmox.com>; Fri, 26 Jan 2024 14:27:45 +0100 (CET)
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 <pve-devel@lists.proxmox.com>; Fri, 26 Jan 2024 14:27:44 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DF89C45EF0
for <pve-devel@lists.proxmox.com>; Fri, 26 Jan 2024 14:27:43 +0100 (CET)
Message-ID: <5b1df1d2-c9b9-4c79-8862-895eee4b3452@proxmox.com>
Date: Fri, 26 Jan 2024 14:27:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
References: <20231120141852.1105425-1-d.csapak@proxmox.com>
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <20231120141852.1105425-1-d.csapak@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.074 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
T_SCC_BODY_TEXT_LINE -0.01 -
Subject: Re: [pve-devel] [PATCH manager] fix #4873: use last used backup
storage for the storage selector
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2024 13:27:45 -0000
Am 20.11.23 um 15:18 schrieb Dominik Csapak:
> for this, we invent the 'storageStateId' parameter that is undeifned by
> default, but if set, the storage selector saves it's value on every
> change there and on initial load (when no value is set from outside)
> loads it from there and uses that as its value.
>
> for now only use it for the selection of backup storages namely in:
> * backup grid
> * "backup now" edit window
> * backup job edit window
>
> in the future we could use that to have a 'last used disk image' or
> 'last used iso' storage too if this approach fits
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>
> the backup job edit is a bit weird and probably warrants a bit of
> discussion, since the interaction when editing an existing job is imho
> unexpected:
>
> 1. select backup storage X in backup grid
> 2. edit a backup job where storage Y is selected (that happens
> correctly) but don't touch the storage field
> 3. now storage Y is the last used and selected on the grids
>
Agreed, but it's still more convenient with the patch than without.
Could we maybe only enable the state update from the second change event
onward? AFAIU, there will always be one change event to set the initial
value and for that we could simply not update the state.
> diff --git a/www/manager6/form/StorageSelector.js b/www/manager6/form/StorageSelector.js
> index 872bc1ab..0a43712f 100644
> --- a/www/manager6/form/StorageSelector.js
> +++ b/www/manager6/form/StorageSelector.js
> @@ -147,6 +147,15 @@ Ext.define('PVE.form.StorageSelector', {
> me.reloadStorageList();
> },
>
> + listeners: {
> + change: function(selector, storage) {
> + if (selector.storageStateId){
eslint complains here because of missing space
> + let sp = Ext.state.Manager.getProvider();
> + sp.set(selector.storageStateId, storage);
Is this state fully global? If yes, is limiting it to instances of the
'PVE.form.StorageSelector' xtype possible/feasible?
> + }
> + },
> + },
> +
> initComponent: function() {
> var me = this;
>