From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <l.wagner@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 425459B1BA
for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:03:31 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 2437E15A77
for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:03:31 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:03:30 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4AEE44335E
for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:03:30 +0100 (CET)
Message-ID: <69565345-fbc5-478c-a2cf-4c83b5f1bba1@proxmox.com>
Date: Mon, 20 Nov 2023 10:03:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20231114130000.565122-1-l.wagner@proxmox.com>
<80bd1a0b-6435-482a-bca0-3ee49e7dd1ce@proxmox.com>
Content-Language: de-AT, en-US
From: Lukas Wagner <l.wagner@proxmox.com>
In-Reply-To: <80bd1a0b-6435-482a-bca0-3ee49e7dd1ce@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.009 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
T_SCC_BODY_TEXT_LINE -0.01 -
Subject: Re: [pve-devel] [PATCH v2 many 00/52] revamp notifications;
smtp endpoints; system mail
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2023 09:03:31 -0000
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