[pve-devel] [PATCH many 00/27] overhaul notification system, use matchers instead of filters

[Lukas Wagner]

Hi, thanks for your input.

On 11/13/23 15:34, Dominik Csapak wrote:
> a few high level ui things
> (i did not look too deeply in the code, but i'll send
> probably some comments there too)
> 
Just as a warning, the tree code/data binding is definitely not as clean 
as it could be right now, a cleanup patch will follow. I just wanted to 
get these patches out ASAP ;)

> that probably was already there, but i find the all/any + invert 
> combination
> confusing (i had to think about it for a bit before getting a grasp on it)
> 
> i would propose we can write the four options out what they mean
> and internally convert them to all/any + invert, e.g.
> 
> 'all rule match'
> 'any rule match'
> 'at least one rule does not match' (all + invert)
> 'no rule matches' (any + invert)

I was considering this as well and discussed both approaches with Aaron.
He was slightly in favor of the one I implemented, so I went with that.
But now that I think about it again I think I like this version better, 
I'll send a followup for this (since this is is purely cosmetic).
> 
> (also is the change from and/or to all/any not a breaking change?,
> did we expose this in the api yet ?)

Well, the switch-over from filters to matchers is breaking as a whole, 
but it only ever hit pvetest, it is not a big problem.
(config parsing was adapted so that it will clean out 'old' entries)
The notification stuff was merged a bit too eagerly, this rework 
attempts to fix some of the issues with the first approach.
> 
> second, we already have a very similar interface in the guest wizard for
> the disks, and there we have the remove button inline,
> i guess we should keep the style consistent
Noted, i'll put it on my list for followups.

> 
> third, do we really need the tree? we basically have the
> four options from above, and then a list of the matches
> 
> wouldn't it be enough to seperate them?

The tree was a conscious decision, because at some point I want to 
support 'sub-matchers' - where a matcher can reference another matcher. 
that way users can compose arbitrary boolean formulas, e.g.:

   All of
     match ...
     match ...
     any of
         match ...
         match ...

For best UX, the sub-matchers shall be configurable within a single 
dialog, and this is the reason why I went with a tree widget.


> 
> e.g. have a dropdown with the four options + a list instead of a tree?
> 
> also currently the match options are not really verified before
> i can submit the form
> 

True, will fix this in a followup.

Thx again!

-- 
- Lukas