From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <l.nunner@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 BE93DBFD5
for <pmg-devel@lists.proxmox.com>; Thu, 14 Sep 2023 11:52:51 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A1DF136B36
for <pmg-devel@lists.proxmox.com>; Thu, 14 Sep 2023 11:52:51 +0200 (CEST)
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 <pmg-devel@lists.proxmox.com>; Thu, 14 Sep 2023 11:52:50 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 459F8472AD
for <pmg-devel@lists.proxmox.com>; Thu, 14 Sep 2023 11:52:50 +0200 (CEST)
From: Leo Nunner <l.nunner@proxmox.com>
To: pmg-devel@lists.proxmox.com
Date: Thu, 14 Sep 2023 11:52:21 +0200
Message-Id: <20230914095234.115469-1-l.nunner@proxmox.com>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.099 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
Subject: [pmg-devel] [PATCH WIP api/gui] Extend rule system
X-BeenThere: pmg-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Mail Gateway development discussion
<pmg-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pmg-devel>,
<mailto:pmg-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pmg-devel/>
List-Post: <mailto:pmg-devel@lists.proxmox.com>
List-Help: <mailto:pmg-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel>,
<mailto:pmg-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2023 09:52:51 -0000
This is a WIP series to rework the PMG rule system by adding the
capabiliy to negate and group objects inside rules. Negated objects will
only match if their conditions are not met.
Match groups allow objects of the same type to be grouped together. A
match group evaluates like one big object, only evaluating as a match if
all objects that are contained inside the group match. In contrast to
previous versions, it is now possible to have multiple match groups for
each object type. They can also be named to make their purpose clearer
at first glance.
Match groups can be visualized as follows:
Rule
- 'Who' Objects
- Match group
Object 1
Object 2
Object 3
- Object 4
The 'Who' objects will only match if either (Object 1 AND Object 2 AND
Object 3) evaluates to true, or if Object 4 evaluates to true. This
means that match groups are connected via logical OR to all other
top-level objects inside the rule, while all objects contained inside
the group are connected via logical AND.
Since this series is still WIP and has been changed since the last
iteration, some things are still missing:
- The matching logic for negation needs proper implementation
The last iteration of this series had some fundamental errors in
how negation was handled for some object types. Especially for
'What' objects it can be rather hard to define what negation
entails.
- The matching logic for match groups
Since we now have multiple match groups for each object type,
the matching logic needs to be adapted accordingly. This could
be achieved by first going through all objects which do not have
their MatchGroup field set, and then going through all match
groups associated with that rule (the facilities for which are
already there).
- UI Tweaks
The UI for match groups still needs some tweaks, such as edit
functionality for match groups (which also still needs to be
implemented in the API), reloading the tree after adding a
group, and maybe changing some icons (negation comes to mind).
pmg-api:
Leo Nunner (11):
negation: add field to database
negation: parse negation value into objects
negation: expand/implement API endpoints
negation: implement matching logic
match groups: update database schema
match groups: add functions for database access
match groups: parse field into objects
match groups: add API endpoints for create/delete
match groups: list match groups in rule API
match groups: update existing object API endpoints
match groups: implement matching logic
src/PMG/API2/ObjectGroupHelpers.pm | 10 +-
src/PMG/API2/RuleDB.pm | 4 +-
src/PMG/API2/Rules.pm | 202 ++++++++++++++++++++++++-
src/PMG/DBTools.pm | 40 +++++
src/PMG/RuleCache.pm | 61 ++++++--
src/PMG/RuleDB.pm | 131 +++++++++++++++-
src/PMG/RuleDB/ArchiveFilter.pm | 6 +-
src/PMG/RuleDB/ContentTypeFilter.pm | 6 +-
src/PMG/RuleDB/MatchArchiveFilename.pm | 4 +-
src/PMG/RuleDB/MatchField.pm | 2 +-
src/PMG/RuleDB/MatchFilename.pm | 2 +-
11 files changed, 445 insertions(+), 23 deletions(-)
pmg-gui:
Leo Nunner (2):
negate objects inside rules
introduce logical 'and' for rules
css/ext6-pmg.css | 20 +++
js/RuleInfo.js | 433 +++++++++++++++++++++++++++++++++++++++--------
js/Utils.js | 14 +-
3 files changed, 391 insertions(+), 76 deletions(-)
--
2.39.2