Re: [pve-devel] [PATCH v2 many 00/52] revamp notifications; smtp endpoints; system mail

[Dominik Csapak <d.csapak@proxmox.com>]

On 11/20/23 10:03, Lukas Wagner wrote:
> 
> 
> On 11/17/23 09:41, Dominik Csapak wrote:
>> one additional comment to the ux:
>>
>> the match field could use a bit of improvement:
>>
>> the docs describe the current fields, but for users that
>> don't deep dive into the docs first it may be confusing having
>> a simple text input field for that
>>
>> at least when the type is 'exact' we could offer a
>> dropdown for the 'type' value (can still be editable)
> 
> I'm actually evaluating if it would make sense to have a separate
> 'match-type' match rule. That one would use the 'type' field
> in the notification metadata, but would be a bit more obvious to use for the user.
> 
> I think filtering notifications by type is probably going to be one of the most common things a user 
> wants to do. Right now, if a user only
> cares about a subset of notification types, e.g. backups and replication, a matcher would could look 
> like this:
> 
> matcher: test
>      mode any
>      match-field exact:type=vzdump
>      match-field exact:type=replication
> 
> Here, we have to use the 'any' mode, so this is awkward, if we also want to filter based on severity.
> 
> 
> Alternatively, a regex-based solution could be used:
> 
> matcher: test2
>      match-field regex:type=^(vzdump|replication)$
> 
> This requires regex knowledge, and the resulting regular expression can become very long if one 
> wants to match many other types of notifications.
> 
> A 'match-type' rule would simplify this by simply allowing one to list all notification types on 
> wants to match, eg.
> 
> matcher: test3
>      match-type vzdump,replication
> 
> 
> For this 'specialized' match-rule we could easily add a list of known
> values in a drop-down (first hardcoded in the UI, later retrieved via an API call)

maybe having it more generic and making it 'match-list' with a property and multiple
values would make more sense? altough that would be very similar to allow
nesting of modes e.g.

mode all
  - mode any
    - match-field exact:type=foo
    - match-field exact:type=foo
  - match-severity:...

would that be feasible to do (probably not in the short term)?

> 
>>
>> in the mid/long term i think having a backend generated list
>> of those somehow would make sense (i.e. some kind
>> of 'registering' and an endpoint that lists the types,
>> or other metadata) but i think that was planned by you anyway
>> (or something along those lines?)
>>
> 
> Yup, that's on my todo-list, having something like a notification
> registry, where we can register notification types, their templates
> (probably separate templates for plain text/HTML, as I don't quite like
> how rendering from a single template turned out in the end, too finicky and lacking flexibility), 
> and the params needed to render the template.
> That way we can enumerate them in the UI quite easily (and
> also auto-generate the list of notifications in the docs)
> 
>> also it would be good to have a link to the docs on the
>> filter edit panel to the relevant section
>> (e.g. for such things as the types/metadata/etc.)
>>
> Noted, will be added in a follow-up.
>