[pve-devel] [PATCH manager 2/2] gui: BackupView: improve filtering of backups

[Thomas Lamprecht]

On 2/24/20 9:35 AM, Dominik Csapak wrote:
> On 2/21/20 4:33 PM, Thomas Lamprecht wrote:
>> Am 2/21/20 um 11:02 AM schrieb Dominik Csapak:
>>> use 'gridfilter' plugin to filter by vmid (returned from the api),
>>> but leave the 'search' textbox (so that the user can still search
>>> for e.g. a year)
>>>
>>
>> what's the improvement the subject talks about? It's way more hidden now
>> how to also show other VM/CT, one needs to guess right that the slightly-bold
>> and italics rendering of "VMID" means filter applied, click on that, click on
>> filters and then edit that, not sure how much of an improvements this is..
> 
> the improvement is that we filter with info from the api instead of the naming of files. this will help us when we have plugins that do not
> format the names of backups with 'vzdump-qemu-ID-...' (and would not work there)
> 

yes, OK, why not doing a multi colum search and go (i.e. prioritize) for the
VMID first?
I just do not want a implicit knob to filter turned on PLUS the search
field which did it earlier and being still there it thus suggest to be
still able to filter as previously - IMO not a good design/UX pattern to
give users - it'll for sure confuse people.

> as for the filtering itself, we already use that kind of filters
> in the 'bulk' windows, so it is not unprecedented, though
> i agree we could make it a little more obvious with e.g. css
> (more contrast, maybe an icon?)

we do not use it there. We allow to use it - that are two very different
things.

Icon makes things better, but as replied to the icon patch does not solves
this.


> 
> the other alternative (that i wanted to avoid), is to have
> some 'magic' syntax in the search field to only search for vmid
> (and not for the year e.g.)
> 

various systems  (e.g., github) use a syntax like what:value, which would translate
to "vmid:1005" here - if it works for all columns it /could/ be OK - but not
that I want it, just as idea and to mention that this isn't completely unheard
off :)

>>
>> Also this only works if VMID storage patch is not available, which you just
>> cannot guarantee. If we, why ever, really want to do this I need a fallback
>> here.
>>
> i guess you mean 'is available', and yes thats the point (the api documents the vmid since 2018 as 'optional') but i am not sure
> how we could change that in a good and backwards compatible way...
> (filtering by volid is not really the right thing if we have
> the vmid defined in the api)
> 

what point? the patch surely does not points that out or solves that..