Discord Tickets (revamped)
Ein Fork des selbst betreibbaren Discord-Ticketbots, mit Thread-Modus und dauerhafter Ablaufsteuerung.
Thread- und Forum-Modus beseitigen die Kanalobergrenze, die Bots mit einem Kanal je Ticket begrenzt, HTML-Transkripte bekommen ein zentrales Dashboard, und jede geplante Aufgabe ist von prozessinternen Timern auf Temporal umgezogen. Die Weboberfläche wurde in dasselbe Repository überführt.
Was es ist
Ein Fork des am weitesten verbreiteten selbst betreibbaren Ticketbots für Discord, mit mehr Funktionen und weniger Fehlern.
Das Ursprungsprojekt steht unter GPL-3.0, und dieser Fork ebenso. Das ist keine Entscheidung dieses Forks, und es ist ohnehin das richtige Ergebnis.
Was sich geändert hat
Thread-Modus, der die Ticketobergrenze beseitigt. Ein Kanal je Ticket ist, was die meisten Ticketbots tun, und läuft auf jedem betriebsamen Server in die Kanalgrenzen von Discord. Threads haben diese Grenze nicht und geben dem Team obendrein den besseren Überblick.
Forum-Modus, für öffentlichen Support in einem Forum-Kanal. Ein ungewöhnlicher Zuschnitt, und der richtige, wenn die Antworten für die nächste Person mit demselben Problem lesbar sein sollen.
HTML-Transkripte mit einem zentralen Dashboard, sodass eine Administration ein geschlossenes Ticket findet, ohne zu wissen, in welchem Kanal es einmal lag.
Ein Rückmeldeportal, das alles sammelt, was Nutzerinnen und Nutzer eingereicht haben, statt es in einem Kanal liegen zu lassen, den niemand liest.
Automatische Zuweisung, bei der die erste Person aus dem Team, die kommentiert, das Ticket übernimmt. Zuweisungsverfahren scheitern meist daran, dass sie jemanden brauchen, der sie betreibt. Dieses betreibt sich aus Verhalten, das ohnehin stattfindet.
Dazu Ersatzkategorien für Tickets im Kanalmodus, ein Schließen-mit-Begründung-Knopf, serverbezogene Anpassung des Erscheinungsbilds und der Wegfall der Gesamtobergrenze für Thread- und Forum-Tickets.
Die Weboberfläche wurde in dieses Repository überführt. Früher war sie ein eigenes Projekt. Zwei Repositories für ein Produkt heißt zwei Release-Zyklen, und die Oberfläche war immer die, die zurückfiel.
Alles Geplante läuft auf Temporal
Der Umgang mit liegengebliebenen Tickets, automatisches Schließen, das Wiedereröffnungsfenster, Export und Import von Transkripten und Cron-Automatisierungen sind alle von prozessinternen Timern weggezogen.
Das ist nicht optional, und der Bot verweigert den Start ohne Temporal-Adresse. Das ist ein bewusster Preis. Prozessinterne Timer auf einem Discord-Bot verlieren bei einem Neustart alles, und ein Bot, der neu startet, verliert das automatische Schließen, das er zugesagt hat. Die Abhängigkeit verbindlich statt optional zu machen heißt, dass es ein Verhalten zu durchdenken gibt statt zwei.
Die Folgen stehen ausdrücklich in den Voraussetzungen: Node 20 oder neuer auf glibc, da das native Addon von Temporal keinen musl-Build hat, und MySQL oder PostgreSQL, da die SQLite-Unterstützung entfallen ist.
Wo es steht
151 Commits von mir auf einer Codebasis, deren Historie bis 2019 zurückreicht. Ein Fork, den ich pflege, mit Nennung des Ursprungsprojekts.
Rechtliches: Terms · Privacy notice · Processing agreement