Re: [pbs-devel] [PATCH proxmox-backup v2] ui: tape/BackupOverview: unify and improve tape restore window

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 14.05.21 08:29, Dominik Csapak wrote:
> On 5/12/21 21:34, Thomas Lamprecht wrote:
>> On 12.05.21 13:49, Dominik Csapak wrote:
>>> adds a snapshot list to the restore window where the user can
>>> select distinct snapshots to restore
>>>
>>> this also replaces the restore / restore single button by
>>> inline actions for the media-set, backup groups and snapshots
>>>
>>> when clicking the action for a group/snapshot, the snapshotselector
>>> gets activated and preselected/filtered so that it includes those
>>> snapshots (can be overridden from the user)
>>>
>>> this change means that we now load the media set everytime we open
>>> the window, since we want to have the list of snapshots.
>>> (we could build that from the tree again, or hold it there somewhere as
>>> list, but i do not think we gain much with that, and it simplifies the
>>> datastore selection code a bit)
>>>
>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>> ---
>>> changes from v1:
>>> * fixed snapshot selection checkbox (was in wrong context, looup needs
>>>    to happen on the referenceHolder)
>>> * removed unnecessary 'node' variable in 'restore' function
>>> * fixed 'media-set' text in window (was the text of the node we clicked on)
>>>
>>
>> Recently it seem to me like we alternate between "place every new function and
>> it's use in 42 separate patches" and "dump^W squash three-zillion changes into
>> one" like a metronome, none of those is  ideal IMO.
>>
>> IOW, this really needs to be two patches, one for the content overview changes
>> and the restore widow.
> 
> ok will do
> 
>>
>> Also, from my last reply to the v1 thread:
>>
>>> IMO slightly better than radio-group/checkbox as it removes a UI control
>>> element completely, so less choice/confusion, but without scarifying flexibility,
>>> so IMO a good idea.
>>
>> Now you added the extra checkbox...  Why not just use the grid-header checkbox like
>> PVE backup-job edit-window and tick it by default when restoring a whole set?
>>
>> As said, reduction by one knob without losing any flexibility - seems like a win
>> win to me, or do I overlook something?
>>
>> With the list below the window's aspect ration feels wrong and the list a bit
>> squished, I'd add a few 100s px to the window height to improve that.
>>
> 
> ok this was a misunderstanding then...
> 
> yeah using the 'check all' checkbox makes sense, but then i am unsure
> how to handle filtering.
> 
> now only visible entries get restored, so if a user would (with the check all) filter, it would seem like still all are selected and
> we generate wrong assumptions?
> we *should* be able to uncheck the check all box though to reduce
> confusion, and this seems to me the best way forward.
> 

not sure this is a problem, in the search functionality for the PMG spam
quaratine the not visible entries just get deselected, if the filter is
cleared then nothing needs to be done, at all time the only things
actually selected must be visible (out ov view due to long list naturally
not counted)

> the alternative is that we restore *all* selected entries, filtered or not, but this can be similarly confusing since things get restored that
> weren't visible
> 

I'm a bit confused here, I do not see the problem? Filtering deselects items
which got filtered out, and the rest then falls in place.

> in pve's 'mass *' windows we have a behaviour like the first suggestion,
> but i just noticed, depending on which column gets filtered, the
> 'check all' box sometimes stays checked and sometimes not...
> 
> as for the height, if there are multiple datastores on the media-set
> (idk if you tested with this), there is another grid for the
> datastore mapping, with that the window is already quite tall
> 
> maybe a multi-step 'wizard' would be better?

that or move one grid to a side.

> 
> let the user first select the basic choices (drive,user,etc.)
> then a window with a full-size grid of the snapshots, and then
> depending on what he selected, either a target datastore
> or datastore mapping input?
> 
> (or the snapshots first, and the rest of the info on the second panel?)
>