[pmg-devel] [PATCH pmg-api/gui/docs, proxmox-widget-toolkit] Extend rule system

[Thomas Lamprecht]

Am 11/04/2023 um 13:04 schrieb Leo Nunner:
> On 2023-04-11 11:52, Thomas Lamprecht wrote:
>> For now some higher level review inline from my side, not sure if I get to
>> a more in-depth for each patch soonish.
>>
>> Am 07/04/2023 um 15:42 schrieb Leo Nunner:
>>> This series introduces two new features for the PMG rule system: object
>>> negation, and match groups. Negation allows the user to negate objects
>>> inside a rule, meaning that they will evaluate to true if their
>>> condition is NOT fulfilled.
>> Do we really don't have any test system for the rule system, if that'd be some
>> technical debt to address probably rather sooner than later.
> We have regression tests for PMG, which should already cover this AFAIK.

Yeah I know of those regression tests, but a lot of the rule system would
not require a (postgres) DB to be spun up, but could often run on a higher
level, e.g., by mocking the higher level methods; iow. more like integrated
test that, while covering a smaller/more specific surface area, can be hosted
in the pmg-api repo directly and run on every package build, vs. the more
complex integration regression test suite that also contains some possibly
sensible material. I mean, the existing regression tests are half-way between
some suite that tests explicitly the external API/mail-transports endpoints only
and some internal testing done.

Also, you nobody mention that you have added, or will add, explicit tests for
the new features ;-)

>>> The second feature, match groups, allows objects to be chained together.
>>> A match group functions as a container for multiple other objects; it
>>> will only evaluate to true if all its members evaluate to true. Match groups
>>> are connected via logical 'or' to all other objects inside the rule;
>>> take the following rule system:
>>>
>>> - Rule
>>>     - Match Group
>>> 	- Object 1
>>> 	- Object 2
>>>     - Object 3
>>>
>>> It will match if either (Object 1 && Object 2), or if Object 3
>>> evaluate to true.
>> Why not allow or matches? Most mail filter tools (like e.g., the x-sieve
>> fronted of open-xchange) allow to configure if all or any of a group's matching
>> rules must trigger for the whole group to be true.
>>
>> I mean, OR matching can be workarounded by duplicated rules but if we add
>> groups with AND combination, then OR is something that I'd think is also
>> expected to be there.
> Not sure if I follow…
> 
> - Rule
>     - Who Objects
>         - Object 1
>     - When Objects
>         - Object 2
> 
> You would want something like this to match if either Who *or* When
> produce a match? IIRC those are connected via AND right now.

I hab more a switch for the "Match Group" in mind, i.e., to configure if it
should act as and, or as or. But, tbf, I did not worked with the PMG rule
system that closely in recent times – maybe I'm just missing something here.