From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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 ; 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 , Proxmox VE development discussion 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >