Tickessa 0.8.0
Veröffentlicht am 3. September 2026.
Tickessa 0.8.0 erweitert die bisherige Ticket- und E-Mail-Verwaltung um sichere Quarantäne, versioniertes Wissen, ein getrenntes Hilfeportal, Formularprofile sowie eine kontrollierte KI-Grundlage. Alle öffentlichen und kostenpflichtigen KI-Funktionen bleiben nach dem Update zunächst deaktiviert.
Spamprüfung und Quarantäne
Tickessa kann Spamheader des Mailanbieters, einen optionalen Spamordner, eigene Regeln, Absenderprüfung und unsichere Anhänge vor jeder KI-Verarbeitung auswerten. Unsichere Nachrichten erscheinen in Einstellungen → Quarantäne. Dort entstehen weder KI-Aufrufe noch automatische Antworten. Nur Administratoren können einen Vorgang bewusst in den normalen Eingang freigeben; ursprüngliche Signale und Entscheidung bleiben in der Historie erhalten.
Mehr dazu: Spam, Quarantäne und Papierkorb.
Getrenntes Hilfeportal
Jedes Projekt besitzt einen vorbereiteten stabilen Pfad unter /hilfe/{projekt}. Das öffentliche Portal verwendet einen eigenen Frontend- und API-Einstieg und erhält keinen Zugriff auf interne Sitzungen, Tickets oder Administration. Projektportal, FAQ, Kontakt, Embed, öffentliche KI und Indexierung haben getrennte Freigaben und sind standardmäßig ausgeschaltet.
Mehr dazu: Hilfeportal und Kontaktformulare.
Formularprofile und Themen
Administratoren können das Standardformular eines Projekts, Pflichtfelder, Datenschutzlink, zulässige Origins und öffentliche Themen pflegen. Öffentliche Bezeichnung und interne Kategorie, Priorität oder Bearbeiter bleiben getrennt. Themen besitzen stabile Schlüssel und Versionen, sodass ältere Tickets nachvollziehbar bleiben.
Eine freigegebene Formularanfrage erzeugt genau ein Web-Ticket und eine eingehende Nachricht. Kurzlebiger Token, Mindest-Ausfüllzeit, Honeypot, Rate-Limit, Größenlimits und Idempotenz schützen den Eingang. Anhänge und Bestätigungsmails sind noch nicht freigegeben.
Direkter Link, Embed und Serverintegration
Link, isoliertes Embed, eigene Browseroberfläche und Serverintegration verwenden dieselbe serverseitige Konfiguration und Ticketpipeline. Browser erhalten keinen dauerhaften Schlüssel. Ein Servergeheimnis wird nur einmal ausgegeben und gehört ausschließlich in die geschützte Konfiguration der integrierenden Anwendung.
Versionierte Wissenseinträge
Wissensartikel trennen stabile Identität, aktuelle Arbeitsfassung und veröffentlichte Fassung. Jede Änderung erzeugt eine neue ungeprüfte Version. Ein Administrator muss die aktuelle Version zuerst fachlich freigeben und anschließend getrennt veröffentlichen. Eine neue Arbeitsfassung ersetzt die bisherige Onlineversion nicht automatisch.
Projekt, Zielgruppe, Herkunft, Pfad, Kategorie, Thema, Produktversionen, Gültigkeit, Wiedervorlage, Reihenfolge, Hervorhebung, öffentlicher Inhalt, interne Hinweise, Quellen und interne Referenzen sind getrennt dokumentiert. Besonders wichtig: Der „öffentlich nutzbare Inhalt“ darf niemals vertrauliche Falldaten enthalten; „interne Hinweise“ werden technisch nicht öffentlich ausgeliefert.
Vollständige Feld-für-Feld-Anleitung: Wissenseinträge anlegen und veröffentlichen.
Wissenskandidaten und lokale Suche
Aus einem geprüften KI-Antwortentwurf kann ein anonymisierter, unveröffentlichter Wissenskandidat entstehen. Seine Umwandlung erzeugt zunächst nur einen internen Entwurf mit offener Prüfung. Originalartikel und Textbausteine bleiben in der lokalen MariaDB; Suchindex und spätere Embeddings können vollständig neu aufgebaut werden.
Mehr dazu: Wissenskandidaten, Textbausteine und Suche.
Öffentliche FAQ und Artikelseiten
Das aktivierte Hilfeportal kann fachlich freigegebene, veröffentlichte und projektrichtige Artikel als Suche, Kategorien und stabile Artikelseiten anzeigen. Interne Hinweise, Quellen, Tickets, KI-Läufe und Prüferdaten werden nicht öffentlich ausgeliefert. Neue ungeprüfte Fassungen verändern eine bereits veröffentlichte Version nicht.
Sicherer eigener KI-Zugang
Ein Administrator kann einen eigenen OpenAI-API-Schlüssel verschlüsselt speichern und die Verbindung prüfen. Der Browser erhält den vollständigen Schlüssel nach dem Speichern nicht zurück. Weitere Anbieterprofile sind sichtbar vorbereitet, aber ohne geprüften Adapter nicht aktivierbar.
Ein gespeicherter Schlüssel aktiviert weder Ticketverarbeitung noch automatischen Versand.
Modelle, Aufgaben, Budgets und Fallbacks
Modelle werden je Aufgabe zugeordnet. Installation, Projekt und Aufgabe besitzen getrennte Tages- und Monatsbudgets sowie Warnschwellen. Zeitlimits, Wiederholungen und Aufrufe je Ticket begrenzen technische Fehler und Kosten. Der Not-Aus blockiert KI-Aufrufe, aber nicht die manuelle Arbeit.
Ein Fallback ist standardmäßig aus und darf nur bei klaren technischen Fehlerklassen sowie nach ausdrücklicher Freigabe möglicher Datenempfänger verwendet werden.
Mehr dazu: KI-Anbieter, Aufgaben und Budgets.
Schutz von KI-Eingaben und Ausgaben
Tickessa trennt feste Anweisungen, nicht vertrauenswürdigen Kundentext und freigegebenes Wissen. Inhalte werden bereinigt und begrenzt; erkennbare Geheimnisse und unzulässige Datenkategorien blockieren den Aufruf. Links werden nicht geöffnet und der Provider erhält keine Werkzeuge. Nur streng validierte strukturierte Ergebnisse dürfen als Vorschlag erscheinen.
KI-Assistenz im Ticket
Klassifizierung, Priorität, Zusammenfassung, Wissenssuche und Antwortentwurf sind als prüfbare Vorschläge vorbereitet. Übernahme und Versand bleiben getrennte menschliche Aktionen. Unterhalb der Konfidenzschwelle kann eine Kategorie oder Priorität nicht direkt übernommen werden. Ein Provider-, Guard- oder Budgetfehler lässt die manuelle Ticketarbeit vollständig nutzbar.
Mehr dazu: KI-Assistenz im Ticket.
Antwortprofile und sichere Anrede
Installations-, Projekt- und Kategorieprofile steuern Ton, Du/Sie, Länge, technische Tiefe, Begrüßung, Verabschiedung, Teamidentität, Signatur und Formulierungsvorgaben. Sicherheitsregeln und belegte Fakten haben immer Vorrang. Eine geschlechtsspezifische Anrede wird nur aus einer ausdrücklich bestätigten Ticketangabe verwendet; Tickessa rät nicht anhand des Namens.
Belegte Wissensgrundlage
Vor einem KI-Vorschlag filtert der Server Quellen nach Projekt, Zielgruppe, Veröffentlichung, fachlicher Freigabe, Gültigkeit und Produktversion. Verweist ein Modell auf eine nicht angebotene Quelle, wird sein Ergebnis verworfen. Ohne passende Quelle darf ein Antwortentwurf nur Rückfragen formulieren, aber keine unbelegte Lösung behaupten.
Antwortursprung und Transparenz
Jede versendete Antwort wird unveränderbar als menschlich, KI-unterstützt und menschlich geprüft oder später automatisch durch KI versendet protokolliert. Text- und HTML-Mail enthalten den passenden Hinweis. Projektspezifische Transparenztexte sind versioniert; ältere Versandnachweise ändern sich nicht nachträglich.
Mehr dazu: Antwortursprung und KI-Transparenz.
Vorbereitung realer KI-Qualitätsfälle
Administratoren können aus einem geeigneten gelösten E-Mail- oder Web-Ticket eine getrennte anonymisierte Arbeitsfassung erzeugen. Nutzungsgrundlage, erwartete Kategorie und Priorität, Antwortgrenze, notwendige Punkte, verbotene Aussagen sowie besondere Risiken werden ausdrücklich dokumentiert. Eine gespeicherte Fassung gelangt erst nach erneuter technischer Prüfung und drei menschlichen Bestätigungen in den geschützten Qualitätsdatensatz.
Der Ablauf verändert kein Ursprungsticket, ruft keinen KI-Anbieter auf und versendet keine Nachricht. Erfundene Fälle bleiben ausschließlich technische Prüfdaten; für die spätere Evaluation sind reale, zulässig genutzte und anonymisierte Fälle aus mindestens zwei Projekten erforderlich.
Vollständige Anleitung: Reale KI-Qualitätsfälle vorbereiten.
Betrieb und Prüfung
Die produktive Referenzinstallation wurde vor dem Update vollständig gesichert. Migrationen 007 bis 019 wurden zuerst auf einer lokalen Kopie der Produktionsdaten und danach in Produktion angewendet. Ein zweiter Testlauf bestätigte die Wiederholbarkeit. Produktions-Build, TypeScript, PHP-Tests, Geheimnisprüfung und 35 automatisierte Tests waren erfolgreich.
Nach dem Deployment meldeten Versions- und Health-Endpunkt Tickessa 0.8.0 und ok. Geschützte API- und Privatpfade blieben gesperrt. Vier Postfächer wurden technisch geprüft; es wurde keine Nachricht importiert und keine E-Mail versendet.
Weiterhin nicht freigegeben
- produktive KI-Verarbeitung in der Referenzinstallation,
- automatischer KI-Versand,
- öffentliches Projektportal, FAQ oder Kontaktformular,
- öffentliche Self-Hosting-Installation durch Kunden,
- grafischer Browser-Installationsassistent,
- öffentliche Registrierung.