OTOBO 11.1 – Funktionen, Installation & Upgrade

In diesem Guide: Was stabiles OTOBO 11.1 ändert, welchen Tag Sie installieren und was das Upgrade von 11.0 oder von der 11.1-Beta verlangt.

Verwandte Themen: OTOBO-11.0-Funktionen · Installation · Docker Compose · Aktualisieren

OTOBO 11.1 ist das aktuelle stabile Minor-Release des Open-Source-Ticketsystems. Rother OSS hat es am 26. Oktober 2026 als stabil veröffentlicht (englische Meldung vom 27. Oktober 2026). Der Git-Tag ist rel-11_1_1, in CHANGES.md als OTOBO 11.1.1 geführt. Es baut auf CMDB, dynamischen Formularen und Docker-Stack von OTOBO 11.0 auf.

Offizielle Notes: OTOBO 11.1. Beta-Historie: Beta, Beta2, Beta3. Quell-Changelog: CHANGES.md auf rel-11_1.

Release-Stand

Build	Datum	Rolle
11.1.0 Beta	24. Juni 2026	Erste öffentliche Beta
11.1.0 Beta2	27. Juli 2026	Security-Patch (Session-Bindung des Upload-Caches, CSRF bei Ticket-Aktionen, Template-XSS)
11.1.0 Beta3	16. September 2026	Security-Patch. Hochkritische HTTP-Basic-Auth-Session-Übernahme in speziellen Setups
11.1.1	26. Oktober 2026	Stabil. Tag rel-11_1_1 auf otobo und otobo-docker

Installieren Sie 11.1.1. Beta3 ist nicht mehr der aktuelle Stand. Ab 11.1 haben Anwendung und Docker-Projekt getrennte Release-Zyklen. Ein späterer Docker-Tag muss nicht dieselbe Patch-Nummer tragen. Beide Repositories prüfen, bevor Sie einen Tag festnageln. Beispieldateien nennen Versionen klarer, und latest-Images bleiben gepflegt.

Support-Fenster laut OTOBO-Downloadseite:

Linie	Veröffentlichung	End of Life
11.1	Oktober 2026	Nicht vor Oktober 2029
11.0	Mai 2024	Nicht vor Mai 2028
10.1	Mai 2022	Mai 2027 (sechs Monate nach 11.1)
10.0	Juli 2020	1. Januar 2026 (bereits beendet)

Ticketbearbeitung

Agenten verbringen den Tag im Ticket. 11.1 verkürzt diese Arbeit.

• Elasticsearch im Core. Weitere Dialoge, Feldabfragen und boolesche Syntax wie Title:Test* AND Body:Test* oder AND / NOT. Boost-Suffixe an Suchfeld-Attributen werden vollständig unterstützt. Artikelbearbeitungen werden korrekt indexiert. Das Elasticsearch-Erweiterungspaket entfällt.
• Ähnliche Tickets. Ein Elasticsearch-Widget in der Ticket-Zoom-Ansicht zeigt verwandte Tickets ohne manuelle Suche. Bei laufendem Elasticsearch ist nichts extra zu aktivieren.
• Artikelverlauf. Bearbeiten inklusive Zeiterfassung ist Standard. In der Ticket-Zoom-Ansicht lassen sich Artikel bearbeiten, löschen oder anpinnen. Texte externer Artikel (nicht E-Mails), dynamische Felder an Artikeln und Attribute wie die Sichtbarkeit sind editierbar. Der Editor öffnet im Vollbild und unterstützt Checklisten (CKEditor 5).
• Listenfilter. Ticketlisten nehmen mehrere Filter gleichzeitig und behalten diese Ansicht.
• Kundenlisten. Nach einer festgelegten Zeit (Standard 24 Stunden) wechselt die Anzeige vom Ticketalter auf die Erstellzeit.
• Kundensuche. Volltextsuche im Kundenportal liegt im Core.

Prozessmanagement

• Namespaces gruppieren Prozesselemente, damit große Setups sortierbar bleiben. Die Sortierung im Admin-Bereich berücksichtigt diese Namespaces.
• Global oder prozess-spezifisch. Eine Checkbox markiert ein Element für alle Prozesse oder nur für einen. Beim Kopieren eines Prozesses mit privaten Elementen werden Layout und Pfad korrekt ersetzt.
• Übergänge unterstützen Not, Any und All, einschließlich Prüfung auf leere Felder. Felder in einem Set sprechen Sie als Field1::Field2 an. Array-Operatoren gelten auch für Dynamic-Field-Sets.
• Übergangsaktionen. DynamicFieldSet nimmt den Parameter ExternalSource, damit eingehende Werte als externe Quelle gelten. TicketCustomerSet akzeptiert Referenzfeld-Werte über das Tag _Data.
• Vorlagen in Prozessdialogen. Ticket-Vorlagen funktionieren in Prozessdialogen und können den nächsten Ticketstatus setzen.
• Kundenoberfläche. Prozess- und Aktivitätsdetails lassen sich ausblenden.
• Dynamische Felder als Steuerung. Referenzfelder ersetzen rohe Objekt-IDs, und Feld-Sets können den Prozess steuern.

Dynamische Felder

Referenzfelder verknüpfen FAQ-Artikel, Services, Kunden, Kundenbenutzer oder ConfigItems mit einem Ticket oder untereinander. Linsenfelder können auf Referenzen und auf Sets zeigen, sodass Agenten verknüpfte Details sehen, ohne das Objekt zu öffnen. Multi-Value-Referenzfelder zeigen mehrere Links (zuerst Ticket-Zoom und Config-Zoom; weitere Masken folgen).

Weitere Feldänderungen:

• ACLs gelten für Felder innerhalb eines Sets und auch in der Antwortmaske der Agentenoberfläche.
• Antwort-Dialoge im Kundenbereich lassen sich in Dynamic-Field-Screens zuordnen.
• Dynamische Felder vom Typ Database können in Sets liegen, mit engeren Filtern für auswählbare Datenbankfelder.
• Skriptfelder können FieldTypeSettings nutzen.
• Admin → Dynamische Felder filtert nach Feldtyp.
• Die Darstellung von Sets im Dynamic-Field-Widget der Ticket-Zoom-Ansicht ist klarer.
• Hide/Show für Sets, Linsen und Referenzfelder wurde korrigiert, auch der Artikelbereich bei der Kundenticketerstellung, wenn das Formular dynamisch aktualisiert.
• Pflicht-Referenzfelder mit Autovervollständigung validieren korrekt. Import/Export verwirft Referenzfeld-Attribute nicht mehr.
• Das Leeren von Update-Events an Skriptfeldern wird in der Datenbank gespeichert.

Sicherheit und Authentifizierung

• OAuth-Token-Verwaltung liegt im Core (früher das Paket MailAccountOAuth2). Tokens decken POP, IMAP und jetzt auch SMTP ab, plus ausgehende Webservices. Passwortwechsel pflegen Sie an einer Stelle.
• OpenID Connect ist Single Sign-On für Agenten und Kunden. Separate OTOBO-Passwörter sind optional, sobald der Unternehmens-Identity-Provider angebunden ist.
• Webservices akzeptieren OIDC/OAuth2. Ausgehende Aufrufe können XSLT-Datentypen wie Array oder Boolean erzwingen und Anhänge als multipart/form-data senden (nötig für Jira, OpenProject und ähnliche APIs).
• Datenbanktreiber. Das Backend wechselt von DBD::mysql auf DBD::MariaDB. Verschlüsselte Verbindungen für MySQL und MariaDB sind verfügbar, und der Installer lässt das Authentifizierungs-Plugin wählen. Ein Daemon-Absturz in DBD::MariaDB disconnect_all() während der Global Destruction (auf Beta1 mit DBD::MariaDB 1.24) ist behoben.
• Nginx setzt server_tokens off.
• Beta-Security-Fixes bleiben in 11.1.1: Session-gebundener Upload-Cache, CSRF bei MarkAsImportant und QuickClose, Template-XSS und die hochkritische HTTP-Basic-Auth-Session-Übernahme.
• 11.1.1 prüft zusätzlich die Berechtigung bei EmailOutbound und Forward unabhängig von der Subaction (#6220).

Datenaustausch und Administration

• Konfiguration als CSV. Prozesse, dynamische Felder, Benachrichtigungen, Queues und ACLs exportieren nach CSV und importieren wieder an der Maske, in der Sie sie pflegen.
• Objekt-Import/Export liegt unter Admin → Import/Export für Tickets, Kunden, Kundenbenutzer und ConfigItems. Der Kundenfirmen-Import übernimmt Werte dynamischer Felder. Das waren die Pakete ImportExportCustomerCompany und ImportExportStandardObjects.
• Externe Ticket-Updates können den Identifier des Fremdsystems nutzen (früher TicketUpdateOperationExternalIdentifier).
• PostMaster. Kundenbenutzer lassen sich aus Informationen im E-Mail-Text setzen (früher PostMasterXFromHeader). Filter haben einen Gültigkeitsstatus, die Übersicht zeigt „Stoppen nach Treffer“, und die Anhängererkennung wurde neu geschrieben.
• LDAP. Der verschachtelte Sync nutzt das vollständige Attribut memberurl.
• Reports. Diagramme unter Docker zeichnet Gnuplot statt Chromium (#3550). Das verkleinert das Image und entfernt Abhängigkeiten, die nur der Browser brauchte. Ein lokales Image behält Chromium-Diagramme. Die Vorgabe von Stats::CustomerUserLoginsAsMultiSelect hat sich geändert (#6296).
• Docker-Cache ist ein Dateisystem-Cache statt Redis (#5728).
• Natives systemd hängt nicht mehr an entrypoint.sh.
• Backups können Symlinks folgen.
• Kundenoberfläche. Neue CSS-Farbvariable für Links, breitere Auswahllisten, korrigierte Initialen im Platzhalter-Avatar und Barrierefreiheit (Auswahlfelder nutzen nicht mehr die ARIA-Rolle search; die Hauptnavigation wurde angepasst).
• Rich Text. Schriftgröße und Zeilenhöhe wurden überarbeitet. Editor-Menüs schneidet overflow: hidden auf .FieldCell und .RichTextField nicht mehr ab. Die Höhenberechnung des CKEditors wurde korrigiert.

Pakete im Framework

Diese Pakete auf 11.1 nicht erneut separat installieren:

Früheres Paket	Im Core
Elasticsearch-Erweiterung	Feldsuche, ähnliche Tickets, Indexierung von Artikeländerungen
ExtendedArticleEdit	Artikel bearbeiten, löschen und anpinnen, inklusive Zeiterfassung
CK5-FullWindowMode	Vollbild-Editor und Checklisten
CustomerTicketSearch	Volltextsuche im Kundenportal
ProcessTicketTemplates	Ticket-Vorlagen in Prozessdialogen
ImportExportCustomerCompany	Kunden-Import/Export inklusive dynamischer Felder
ImportExportStandardObjects	Tickets, Kundenbenutzer und ConfigItems unter Admin → Import/Export
TicketUpdateOperationExternalIdentifier	Fremdsysteme über deren Ticket-Identifier zuordnen
PostMasterXFromHeader	Kundenbenutzer aus dem E-Mail-Text setzen
MailAccountOAuth2	Zentrale OAuth-Tokens für E-Mail und ausgehende Webservices

Fehlerbehebungen in 11.1.1

Diese Fixes nennt die stabile Release Note zusätzlich zur Beta-Linie:

• Abbrüche im Upgrade, darunter ITSM-Systeme, die den Wechsel auf 11.1 nicht schafften, und DBUpdate-to-11.1.pl, das scheiterte, wenn lang laufende Datenbanken die Dynamic Fields für ProcessManagement nicht hatten. Das Skript liefert jetzt einen sinnvollen Exit-Code.
• Elasticsearch-Migration, wenn kein Elasticsearch-Webservice existiert.
• Zu strenge Rechteprüfung verschachtelter Queues in AgentTicketQueue nach #6092.
• TicketACL::Autoselect in Prozessen.
• Nullwerte fehlten in den Kundeninformationen der Ticket-Zoom-Ansicht.
• Core-Dump bei Maint::PostMaster::MailAccountFetch auf dem 11.1-Branch.
• Fehlender Index auf article_version.source_article_id.
• Fehler bei Linse-auf-Set, die Importdaten beschädigten, und Linsen-Sets, die das AJAX-Formularupdate zurücksetzten, wenn ein Referenzfeld wieder erschien.
• Auswahlmenüs und zu schmale Dropdowns in der Kundenoberfläche.
• Ungültige Pakete ohne Fehlermeldung, doppelte Einträge in der Kerberos-Nginx-Vorlage und Foreign-Key-Checks, die in Kernel::System::DB::new() aktiv blieben.

OTOBO 11.1 Installation

Docker bleibt der empfohlene Weg.

1. otobo-docker mit Tag rel-11_1_1 klonen (11.0 nutzt rel-11_0; der letzte 11.0-Tag zum Zeitpunkt des 11.1-Releases ist rel-11_0_18).
2. .docker_compose_env_http oder .docker_compose_env_https nach .env kopieren und OTOBO_DB_ROOT_PASSWORD setzen.
3. Stack starten und http://ihr-host/otobo/installer.pl öffnen. Datenbank-Host db lassen. Das Datenbank-Authentifizierungs-Plugin im Installer wählen, wenn Sie verschlüsseltes MariaDB oder MySQL brauchen.

Die native Installation (Ubuntu oder RHEL) lädt ein Archiv von ftp.otobo.org/pub/otobo/, entpackt es nach /opt/otobo, installiert Perl-Abhängigkeiten und stellt Nginx vor Gazelle. Schrittfolgen: 11.1-Installationshandbuch, Ubuntu, Docker. Die Installationsübersicht vergleicht die Tags für 11.1, 11.0 und 10.1.

Upgrade auf OTOBO 11.1

Die 11.1-Update-Anleitung für Ubuntu beschreibt 11.0 → 11.1. Patch-Wechsel innerhalb von 11.1 überspringen die Datenbankmigration. Beta-Nutzer gehen denselben Weg auf 11.1.1.

1. Webserver und OTOBO-Daemon stoppen.
2. /opt/otobo und die Datenbank sichern.
3. Lokale Dateiänderungen paketieren. Unter Docker schreibt der Updater ein Backup nach /opt/otobo_update/ und behält unpaketierte Edits nicht.
4. Neues Release über /opt/otobo entpacken oder in otobo-docker rel-11_1_1 auschecken.
5. Die Perl-Module installieren, die der 11.1-Guide für Ubuntu oder Debian vor der Migration nennt.
6. scripts/DBUpdate-to-11.1.pl nur ausführen, wenn Sie 11.0 verlassen (oder eine 11.1-Beta, auf der die Migration noch nicht lief).
7. E-Mail-OAuth migrieren. MailAccountOAuth2 ist kein Add-on mehr. Die OAuth-Schritte stehen in den 11.1-Release-Notes.
8. Konfiguration neu aufbauen und Dienste starten. Statistikdiagramme prüfen. Sie rendern mit Gnuplot. Chromium bleibt nur über ein lokales Image, wie in diesen Release Notes beschrieben.

[!IMPORTANT] Drei Backend-Änderungen brauchen einen manuellen Schritt: das Docker-Backupverzeichnis /opt/otobo_update/, die Übernahme von MailAccountOAuth2 und Gnuplot statt Chromium für Report-Diagramme.

Vergleich mit anderen Versionen

Linie	Installieren, wenn	Docker-Tag	Support
11.1.1	Neue Produktivsysteme	rel-11_1_1	Stabil seit 26. Oktober 2026. End of Life nicht vor Oktober 2029
11.0	Sie müssen auf 11.0 bleiben	rel-11_0 (letzter Tag rel-11_0_18)	Unterstützt. End of Life nicht vor Mai 2028
10.1	Sie müssen auf 10.x bleiben	rel-10_1	Security-Patches bis Mai 2027
10.0	Nicht installieren	—	End of Life 1. Januar 2026

Den Funktionsumfang von 11.0 (CMDB, dynamische Formulare, Docker), den 11.1 erweitert, beschreibt OTOBO Version 11.

Häufig gestellte Fragen

Ist OTOBO 11.1 produktiv einsetzbar?

Ja. OTOBO 11.1 hat die Beta am 26. Oktober 2026 verlassen. Der stabile Patch ist OTOBO 11.1.1 (Git-Tag rel-11_1_1). Rother OSS unterstützt diese Linie mindestens bis Oktober 2029. Beta-Systeme auf 11.1.1 heben; nicht auf 11.1.0 Beta3 bleiben.

Wie installiere ich OTOBO 11.1?

Empfohlen ist Docker Compose mit dem otobo-docker-Tag rel-11_1_1. Die HTTP- oder HTTPS-Env-Datei nach .env kopieren, OTOBO_DB_ROOT_PASSWORD setzen und installer.pl öffnen. Eine native Installation nutzt das Archiv von https://ftp.otobo.org/pub/otobo/ und das offizielle 11.1-Handbuch.

Was muss ich beim Upgrade auf OTOBO 11.1 anpassen?

Zuerst sichern, dann das Datenbank-Update von 11.0 auf 11.1 ausführen. Unter Docker schreibt der Updater ein Backup nach /opt/otobo_update/, deshalb manuelle Änderungen vorher paketieren. MailAccountOAuth2 liegt im Core und braucht eine manuelle OAuth-Migration. Diagramme in Reports nutzen Gnuplot statt Chromium, außer Sie bauen ein lokales Image mit Chromium.