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 425459B1BA for ; 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 ; 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 ; 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 ; 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 , Proxmox VE development discussion References: <20231114130000.565122-1-l.wagner@proxmox.com> <80bd1a0b-6435-482a-bca0-3ee49e7dd1ce@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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