Re: [pve-devel] [PATCH v2 many 00/52] revamp notifications; smtp endpoints; system mail

[Lukas Wagner <l.wagner@proxmox.com>]

On 11/20/23 10:11, Dominik Csapak wrote:
>> 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)?
> 

This could easily be implemented as an extension to the 'match-field' 
rule by adding another mode:

match-field list:type=vzdump,replication

Maybe 'list' is not the best name for this mode, but you get the idea.

Theoretically, we could have this 'generic' approach in the backend,
while also adding a 'match-type' 'virtual' node type (using the generic 
list-matching) in the UI to make things obvious for the user.

The 'composable' nesting of nodes would be added independently of this.
The implementation in proxmox_notify will be pretty easy, but the UI/API 
handler part could be a bit tricky - since we have to add/modify/delete
multiple matchers 'atomically' in a single transaction (when pressing
OK in the GUI).

So either a 'match-type' or the list-extension would definitely be
nice until we have that - and also afterwards, because you can skip
nested nodes in some cases if you have this feature.

-- 
- Lukas