From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.csapak@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 791C89B1CF
 for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:11:37 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 57DF115D4C
 for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:11:07 +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:11:06 +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 831A443335;
 Mon, 20 Nov 2023 10:11:06 +0100 (CET)
Message-ID: <987d0f8d-26c1-4c56-ad3f-f2e34c45e678@proxmox.com>
Date: Mon, 20 Nov 2023 10:11:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
Content-Language: en-US
To: Lukas Wagner <l.wagner@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>
 <69565345-fbc5-478c-a2cf-4c83b5f1bba1@proxmox.com>
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <69565345-fbc5-478c-a2cf-4c83b5f1bba1@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.017 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:11:37 -0000

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