[pve-devel] [PATCH manager] storage GUI: fix unintuitive sorting order

[pve-devel] [PATCH manager] storage GUI: fix unintuitive sorting order

[Matthias Heiserer]

The backups in the 'Backups' table in Storages are now initially
sorted by column 'Name' ascending.

Previously, they were first sorted by 'vmid' descending, then by date
descending. This was unintuitive as 'vmid' doesn't exist as column
in the GUI, and only 'Date' displayed a sorting arrow.

Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
---
 www/manager6/storage/BackupView.js | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/www/manager6/storage/BackupView.js b/www/manager6/storage/BackupView.js
index 2328c0fc..f02944c9 100644
--- a/www/manager6/storage/BackupView.js
+++ b/www/manager6/storage/BackupView.js
@@ -211,13 +211,9 @@ Ext.define('PVE.storage.BackupView', {
 	me.store.getSorters().clear();
 	me.store.setSorters([
 	    {
-		property: 'vmid',
+		property: 'text',
 		direction: 'ASC',
 	    },
-	    {
-		property: 'vdate',
-		direction: 'DESC',
-	    },
 	]);
     },
 });
-- 
2.30.2

Re: [pve-devel] [PATCH manager] storage GUI: fix unintuitive sorting order

[Fabian Ebner]

Am 18.02.22 um 11:42 schrieb Matthias Heiserer:
> The backups in the 'Backups' table in Storages are now initially
> sorted by column 'Name' ascending.
> 
> Previously, they were first sorted by 'vmid' descending, then by date
> descending. This was unintuitive as 'vmid' doesn't exist as column
> in the GUI, and only 'Date' displayed a sorting arrow.
> 
> Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
> ---
>  www/manager6/storage/BackupView.js | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
Please note that the order was recently intentionally changed to be like
that, see commit 58f4e6ac387561a16ec370812083d60a12dc4cfe

That said, you do have a point. One way to improve the situation might
be to add a vmid column, but we could also think about using a tree view
for backups instead.

@Thomas: Would the latter be okay for you?

Not related to your change, but some more context:

PVE.storage.BackupView is currently derived from
PVE.storage.ContentView, but actually, it caused a lot of special
handling to be added to that base class. If PVE.storage.BackupView were
it's own thing (which is essentially implied if we go with the tree view
approach), PVE.storage.ContentView should also get simpler again.

There also is PVE.grid.BackupView which is used for backups of a single
guest and IMHO it should be merged with the other one, with a few config
options to account for the small differences in behavior.

Re: [pve-devel] [PATCH manager] storage GUI: fix unintuitive sorting order

[Thomas Lamprecht]

On 21.02.22 09:32, Fabian Ebner wrote:
> Am 18.02.22 um 11:42 schrieb Matthias Heiserer:
>> The backups in the 'Backups' table in Storages are now initially
>> sorted by column 'Name' ascending.
>>
>> Previously, they were first sorted by 'vmid' descending, then by date
>> descending. This was unintuitive as 'vmid' doesn't exist as column
>> in the GUI, and only 'Date' displayed a sorting arrow.
>>
>> Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
>> ---
>>  www/manager6/storage/BackupView.js | 6 +-----
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
> Please note that the order was recently intentionally changed to be like
> that, see commit 58f4e6ac387561a16ec370812083d60a12dc4cfe
> 
> That said, you do have a point. One way to improve the situation might
> be to add a vmid column, but we could also think about using a tree view
> for backups instead.
>> @Thomas: Would the latter be okay for you?

A tree view like PBS has would be nice in general IMO for the storage
backup content view, as with lots of VMs that's way easier to browse/work
with than the flat list. IIRC we talked about that already in the past,
in the context of the prune group button, but it wasn't to pressing then
and went off the radar.

Adding the vmid, at least as by-default hidden column, would be the easiest
(quickest) change now though, but this is IMO not to pressing that we need
to do any stop-gap measures.