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

[Lukas Wagner]

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)

> 
> 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.

-- 
- Lukas