Permissions
Die vier Argus-Permissions und wie das Überwachungsmodell funktioniert — wer beobachtet wird, wer ausgenommen ist, wer hinschauen darf.
Argus v1.1.1Paper · Purpur · Folia-safe1.21 – 1.21.x
Argus hat vier Permissions. Zwei davon entscheiden, wer überwacht wird — genau der Teil, den man am ersten Tag falsch macht.
| Permission | Standard | Zweck |
|---|---|---|
argus.admin | op | GUI öffnen, alle Sub-Befehle, Scores löschen. |
argus.monitored | false | Wer das hat, wird überwacht. Ohne diese Permission wird nichts bewertet. |
argus.exempt | false | Wird nie bewertet oder markiert — für den Owner. |
argus.alerts | op | Erhält In-Game-Alerts bei hoher Bedrohung. |
Das Überwachungsmodell
Argus ist bewusst Opt-in. Eine frische Installation überwacht niemanden, denn still jeden Operator auf dem Server zu bewerten ist ein guter Weg, am ersten Tag Rauschen und schlechte Stimmung zu erzeugen.
# die Ränge, die beaufsichtigt werden sollenlp group helper permission set argus.monitored truelp group moderator permission set argus.monitored truelp group admin permission set argus.monitored true # die Person, der der Server gehörtlp user DeinName permission set argus.exempt true # wer die Ergebnisse sehen darflp group admin permission set argus.admin truelp group admin permission set argus.alerts trueargus.admin impliziert kein argus.monitored
Die beiden sind absichtlich unabhängig. Ein Senior-Admin darf das GUI öffnen und gleichzeitig
überwacht werden — das ist der Normalfall. Nur argus.exempt nimmt jemanden aus der Bewertung.
Wie exempt sich wirklich verhält
argus.exempt unterdrückt Bewertung und Markierung für dieses Mitglied. Es macht es nicht
unsichtbar: Normale Aktionen landen weiterhin im Audit-Log, denn das Log ist die Beweiskette — und
eine Lücke in einer Hashkette ist schlimmer als ein langweiliger Eintrag.
Es gibt eine bewusste Ausnahme. Die Unban-Prüfung läuft vor dem Monitored-Check, sodass die Rücknahme eines Bans durch einen nicht überwachten Senior trotzdem die Prüfung auslöst, die denjenigen markiert, der den ursprünglichen Ban gesetzt hat. Ohne das wäre das Muster „Junior bannt, Senior hebt still auf" unsichtbar.
Alerts
argus.alerts entscheidet, wer In-Game-Alerts sieht, sobald ein Mitglied alerts.min-stars
überschreitet. Die Permission ist von argus.admin getrennt, damit du eine kleine Bereitschaftsgruppe
benachrichtigen kannst, ohne allen die Möglichkeit zu geben, Scores zu löschen.
Discord-Alerts werden global konfiguriert und ignorieren diese Permission — siehe Konfiguration.
Ein durchgerechnetes Beispiel
Ein Team mit vier Rängen:
| Rang | argus.admin | argus.monitored | argus.exempt | argus.alerts |
|---|---|---|---|---|
| Owner | ja | nein | ja | ja |
| Admin | ja | ja | nein | ja |
| Moderator | nein | ja | nein | nein |
| Helper | nein | ja | nein | nein |
Admins sind gleichzeitig Beobachter und Beobachtete. Genau das ist der Punkt: Der Rang mit dem
größten Schadenspotenzial ist der Rang, dessen Bewertung sich am meisten lohnt — und die Hashkette
sorgt dafür, dass ein Admin seine eigenen Einträge nicht löschen kann, ohne dass /argus verify es
bemerkt.