Tickessa 0.8.0
Besucher erreichen die freigegebenen Hilfsartikel und den Kontaktweg auf der Projektseite.
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.
Datensparsame Selbsthilfe-Statistik
Eine getrennt freizugebende Projektstatistik zählt Suchen ohne Treffer, häufige Formularthemen, Artikelaufrufe, freiwilliges Ja/Nein-Feedback und anschließende Kontakte. Sie verwendet keine Cookies, speichert keine IP-Adressen oder User-Agents und bildet kein projektübergreifendes Profil. Rohereignisse werden nach kurzer Frist zu sitzungsfreien Tageswerten verdichtet und gelöscht.
Markierte Artikel können nach Bestätigung einen budgetierten internen KI-Überarbeitungsvorschlag erhalten. Die KI sieht nur die freigegebene Artikelfassung und aggregierte Zähler; das Ergebnis bleibt unveröffentlicht und durchläuft den normalen menschlichen Prüf- und Veröffentlichungsablauf.
Mehr dazu: Datensparsame Selbsthilfe-Statistik.
Öffentliche KI-Hilfe mit Quellenpflicht
Eine getrennt freizugebende KI-Seite beantwortet Einzelfragen ausschließlich aus diesen öffentlichen Artikelversionen. Jede sachliche Antwort nennt die verwendeten Artikel als Links. Ohne passende Grundlage, bei geringer Konfidenz, sensiblen Angaben oder Manipulationsversuchen verweigert Tickessa die Antwort und hält den persönlichen Kontakt sichtbar.
Frage und Ergebnis gelangen nur nach ausdrücklicher Besucherbestätigung über einen kurzlebigen lokalen Browserspeicher in das editierbare Kontaktformular. Es gibt keinen automatischen Ticket- oder E-Mail-Versand. Provider-, Aufgaben-, Projekt- und Installationsbudgets sowie zusätzliche öffentliche Rate-Limits begrenzen Kosten und Missbrauch. Die Funktion bleibt nach dem Update deaktiviert.
Mehr dazu: Öffentliche KI-Hilfe aus freigegebenem Wissen.
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.
Tickessa Local AI
Ein installierbarer, versionierter Dienst kann lokale Textmodelle und Embeddings hinter der allgemeinen Tickessa-Providerschnittstelle bereitstellen. Tickessa akzeptiert dafür nur private HTTPS-Ziele und prüft Zertifikat, Kopplungsgeheimnis, Protokoll, Dienstidentität, LAN/VPN sowie direkte oder weitergeleitete Route. Der projektbezogene Modus Nur lokal sperrt Cloudmodelle und Cloud-Fallbacks technisch; Hybrid benötigt die ausdrückliche Freigabe konkreter Datenkategorien.
Der lokale Vektorindex speichert nur Quellkennungen, Prüfsummen und neu erzeugbare Vektoren. Artikel bleiben in MariaDB die fachliche Wahrheit. Dienst- und Pakettests decken Authentifizierung, Offline-Fixture, Inhaltsfreiheit der Indexdatei sowie Installation, Update und Deinstallation ab. Konkrete Modell- und Hardwareempfehlungen bleiben bis zu realen, reproduzierbaren Benchmarks ausdrücklich offen.
Mehr dazu: Tickessa Local AI einrichten.
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
Das Schema bis Migration 026 wurde auf einer frischen MariaDB vollständig und wiederholbar angewendet. Öffentliche KI und Selbsthilfe-Statistik wurden zusätzlich mit synthetischen, getrennten Projekten sowie freigegebenen und nicht freigegebenen Inhalten geprüft. Local AI wurde mit einer vollständig lokalen synthetischen Laufzeit getestet; reale Modell-, Hardware-, LAN-, VPN- und Clusterbenchmarks sind noch keine Produktfreigabe. Produktions-Build, TypeScript, PHP-Unit- und Datenbanktests, Dokumentations-Build, Geheimnisprüfung sowie die automatisierten Architektur- und Sicherheitstests müssen vor der Auslieferung erfolgreich sein.
Für eine produktive Aktualisierung bleiben vollständige Datei- und Datenbanksicherung, Migration, Versions- und Health-Prüfung sowie die Kontrolle geschützter API- und Privatpfade vorgeschrieben. Die Referenzkonfiguration hält öffentliche KI und automatischen Versand auch nach dem Deployment deaktiviert, bis alle gesonderten Freigaben vorliegen.
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.