# Admin-Einstellungen

> Webtrees Modul-Einstellungen

---

Verfügbare Optionen auf der Admin-Seite:

## Ereignis-Katalog

Die Admin-Seite (Events-Abschnitt) und die Ereignisnamen-Vorschläge im Job-Formular werden von einer **Ereignis-Inventur** (`cj_event_catalog`, vom [Tick](../tick) synchronisiert wie die Job-Registry) gespeist. Sie mischt in dieser Prioritätsreihenfolge:

1. [Events](../events), **von Modulen angekündigt** (Manifest-`events`-Abschnitt / `getModuleEvents()`), namespaced `<module>:<name>`
2. [**eingebaute Pseudo-Events**](../events/pseudo) (`cronjob:*`, von den Detektoren)
3. [**Route-Events**](../events/route) (`_route:*`, abgeleitet aus der live Routentabelle)
4. Ereignisnamen, die derzeit **abgehört** werden von einem aktiven Event-Job (Quelle `listening`) — dies deckt Webhook-only-Namen ab

Jeder Eintrag trägt seine Quelle, eine Beschreibung (als Übersetzungsschlüssel gespeichert, nur zur Render-Zeit übersetzt) und die bekannten Payload-Parameter-Namen. Für **Route-Events** wird der Payload **aus dem Routenpfad abgeleitet**: die `{param}`-Platzhalter in der Reihenfolge ihres Auftretens, wobei `{tree}` sich zu `tree` + `tree_name` ausdehnt (spiegelnd, was der live Event-Payload trägt). Für **Pseudo-Events** kommen beide vom Detektor (`description()` / `payloadKeys()`). Die vollständige Liste ist auch das, was das "Ereignisname"-Datalist im Job-Formular bietet. Der Katalog wird als Client-seitige **DataTables** (Sortieren/Filtern/Paginieren) im Events-Abschnitt gerendert.

![Events](img/cj/events.png)

## Befehls-Katalog

Die Befehls-Vorschläge im Job-Formular und die Admin-Seite (Events-Abschnitt) werden von einer **Befehl-Inventur** (`cj_command_catalog`, vom Tick synchronisiert wie die anderen) gespeist. Sie mischt in dieser Prioritätsreihenfolge (erste Quelle gewinnt pro Befehl):

1. die **allowlisteten Core-Befehle** (`tree-export`, `tree-list`, `user-list`, `site-setting`), mit ihren bekannten Parametern
2. Befehle, **von Modulen angekündigt** (Manifest-`commands`-Abschnitt / `getModuleCommands()`) — mit einer Beschreibung und strukturierten Parametern
3. **Modul-CLI-Skripte**, gefunden per Glob (`modules_v4/<module>/cli/*.php`), *außer* für ein Modul, das Befehle angekündigt hat (das Modul kuriert seine eigene Liste, daher werden seine internen Skripte nicht angeboten)

Jeder Eintrag trägt seinen Typ (`module` / `core`), seine Quelle, eine Beschreibung (Übersetzungsschlüssel, zur Render-Zeit übersetzt) und die verfügbaren Parameter (strukturiert: Name, optional, Default, Beschreibung). Im Job-Formular zeigt die Eingabe eines Befehls, der mit einem angekündigten Befehl übereinstimmt, seine Parameter als Hinweis unter dem Feld.

![Befehle](img/cj/commands.png)

## Fehlerbenachrichtigung

Ein Job kann als **Bei Fehler benachrichtigen** markiert werden. Wenn ein solcher Job fehlschlägt (nicht-null Exit oder Timeout), werden die **Administrator**-Konten der Site über webtrees' eigenes `MessageService::deliverMessage()` alarmiert — das über das **interne Nachrichtensystem** und/oder **E-Mail** entsprechend der *eigenen* Kontaktmethode-Präferenz jedes Empfängers liefert. Es werden keine Adressen im Modul gespeichert und kein Kanal ist hartkodiert: die Empfänger sind die Admin-Benutzerkonten, und wie sie erreicht werden, folgt den Nachrichten-Einstellungen der Site.

Die Benachrichtigung trägt den Job-Namen, Status, Exit-Code, Dauer und einen kurzen Schwanz der erfassten Ausgabe. Sie läuft im Tick (keine Web-Anfrage), daher trägt sie keinen Link über den Text hinaus. Ein Benachrichtigungsproblem bricht nie den Tick.