OTRS-Skill: Plugin hier oder eigenes Repo? #7

New Issue

2026-09-05T09:39:44+02:00

jhs commented

2026-09-05 09:39:44 +02:00

Ich habe mir eine CLI für OTRS 5 gebaut (Generic Interface): Tickets suchen,
Metadaten lesen, interne Notizen schreiben, zuweisen, anlegen, seit gestern auch
mit Datei-Anhängen. Sie läuft bei mir als lokaler Claude-Skill
(~/.claude/skills/otrs/) und war bisher nirgends versioniert — das will ich
ändern.

Die Struktur würde in diesen Marketplace passen (plugins/otrs/skills/otrs/ wie
bei humhub und mediawiki), ein OTRS-Plugin gibt es hier noch nicht. Ob es
hier richtig liegt, weiß ich aber nicht — deshalb die Frage an dich, bevor ich
etwas anlege.

Was dagegen spricht: Das Ding ist auf unsere AVV-Lage zugeschnitten. Es
maskiert Namen, Adressen und IPs vor jeder Ausgabe (lokale Namenserkennung über
Ollama), unterdrückt Tickettitel komplett, wenn das Modell nicht antwortet,
führt ein Zugriffsprotokoll mit 90-Tage-Frist und kann bewusst keinen
Mailversand an Kunden. Wer das Plugin installiert, erbt dieses Verhalten, ohne
die Gründe zu kennen. Ohne eigene OTRS-Zugangsdaten läuft es ohnehin nicht.

Was mich mehr umtreibt: Mit sko/ticketing gibt es bereits ein CLI an
derselben Schnittstelle (und mit cbr/Wissensschicht ein Konzept, das OTRS
ebenfalls anfassen wird). Bevor ich ein zweites Werkzeug zementiere:

Soll so etwas grundsätzlich hier als Plugin liegen, oder gehören Werkzeuge
mit Zugangsdaten und Firmen-Spezifika in eigene Repos?
Baust du an ticketing in dieselbe Richtung weiter? Buchen und Schließen
kann es ja bereits — dann wäre sinnvoller, meine Lese- und Notiz-Funktionen
dort einzubringen, statt zwei CLIs zu pflegen.

Ich lege bis zu deiner Antwort nichts an; lokal liegt es jetzt in einem
Git-Repo, damit nichts verloren geht.

Ich habe mir eine CLI für OTRS 5 gebaut (Generic Interface): Tickets suchen, Metadaten lesen, interne Notizen schreiben, zuweisen, anlegen, seit gestern auch mit Datei-Anhängen. Sie läuft bei mir als lokaler Claude-Skill (`~/.claude/skills/otrs/`) und war bisher nirgends versioniert — das will ich ändern. Die Struktur würde in diesen Marketplace passen (`plugins/otrs/skills/otrs/` wie bei `humhub` und `mediawiki`), ein OTRS-Plugin gibt es hier noch nicht. Ob es hier richtig liegt, weiß ich aber nicht — deshalb die Frage an dich, bevor ich etwas anlege. **Was dagegen spricht:** Das Ding ist auf unsere AVV-Lage zugeschnitten. Es maskiert Namen, Adressen und IPs vor jeder Ausgabe (lokale Namenserkennung über Ollama), unterdrückt Tickettitel komplett, wenn das Modell nicht antwortet, führt ein Zugriffsprotokoll mit 90-Tage-Frist und kann bewusst keinen Mailversand an Kunden. Wer das Plugin installiert, erbt dieses Verhalten, ohne die Gründe zu kennen. Ohne eigene OTRS-Zugangsdaten läuft es ohnehin nicht. **Was mich mehr umtreibt:** Mit `sko/ticketing` gibt es bereits ein CLI an derselben Schnittstelle (und mit `cbr/Wissensschicht` ein Konzept, das OTRS ebenfalls anfassen wird). Bevor ich ein zweites Werkzeug zementiere: 1. Soll so etwas grundsätzlich hier als Plugin liegen, oder gehören Werkzeuge mit Zugangsdaten und Firmen-Spezifika in eigene Repos? 2. Baust du an `ticketing` in dieselbe Richtung weiter? Buchen und Schließen kann es ja bereits — dann wäre sinnvoller, meine Lese- und Notiz-Funktionen dort einzubringen, statt zwei CLIs zu pflegen. Ich lege bis zu deiner Antwort nichts an; lokal liegt es jetzt in einem Git-Repo, damit nichts verloren geht.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inmedias.it/claude-plugins#7