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
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
