· Zum Nikolaustag haben wir ein besonderes Geschenk für Sie: Zammad 6.2! 🌟🎁 Das Minor Release bringt verschiedene Verbesserungen mit sich, die darauf abzielen, die Effizienz und Sicherheit unserer Helpdesk-Plattform zu steigern.
Die Gruppenverwaltung von Zammad hat gerade ein Upgrade erhalten! Jetzt funktioniert es wie ein Stammbaum, der Elterngruppen mit Kindgruppen und sogar Großelterngruppen verbindet. Man kann es sich so vorstellen, dass es nachahmt, wie sich größere Unternehmen organisieren. Genau wie Teams in Unternehmen sind die Gruppen von Zammad für die Zusammenarbeit an zugewiesenen Themen konzipiert. Sie bieten einen Rahmen für die Organisation von Aufgaben, helfen bei der Verwaltung des Zugriffs auf Informationen und der Fokussierung auf bestimmte Verantwortungsbereiche.
Ein Beispiel: Wenn ein Unternehmen wächst, werden die Dinge immer komplexer. Mehr Abteilungen, mehr Teams - Sie kennen das sicherlich. Um damit Schritt zu halten, haben wir Zammad flexibler gemacht. Jetzt können Sie Gruppenbäume erstellen, die Ihre Organisationsstruktur widerspiegeln. Es ist wie eine visuelle Karte, die zeigt, was mit was verbunden ist, und die Verwaltung erheblich erleichtert.
Es gibt jedoch keine Vererbung von Mitgliedschaft oder Berechtigungen. Das bedeutet, dass Sie jede Gruppe als individuelle Gruppe behandeln können - auch wenn sie eine Kind-/Elternbeziehung haben. ➡️ Lesen Sie mehr über Gruppeneinstellungen in der Admin-Dokumentation.
Eine leistungsstarke LDAP-Integration, die es Ihnen ermöglicht, eine einzige Wahrheitsquelle zu haben, ist eine unserer vielen großartigen Funktionen von Zammad. Historisch gesehen war bei der Einrichtung einer neuen LDAP-Quelle in unserem Konfigurationsassistenten keine Authentifizierung erforderlich. Aufgrund der sich entwickelnden Landschaft moderner LDAP-Schnittstellen hat Zammad jedoch Anpassungen vorgenommen. Konkret haben wir Änderungen implementiert, um die Hinzufügung neuer Quellen wie Okta LDAP zu erleichtern, die eine Authentifizierung vorschreiben.
Wenn Ihr LDAP-System anonyme Bindungen einschränkt, ist Zammad 6.2 darauf vorbereitet, diese Einschränkung zu identifizieren. Folglich präsentiert Zammad Benutzern anstelle eines vorab ausgefüllten Auswahlfelds jetzt ein bearbeitbares Textfeld "Base DN".
➡️ Erfahren Sie mehr in unserer Admin-Dokumentation.
Benutzerdefinierte Zertifikate und benutzerdefinierte Zertifizierungsstellen (CA)-Zertifikate können nützlich sein, wenn Sie eine sichere Verbindung zwischen Zammad und anderen Systemen herstellen möchten, die benutzerdefinierte Zertifikate verwenden. Zum Beispiel, wenn Sie einen internen LDAP-Server haben, der nicht aus dem Internet erreichbar ist, und Sie eine SSL-verschlüsselte Verbindung wünschen, können Sie ein benutzerdefiniertes Zertifikat verwenden.
Mit Zammad 6.2 haben wir eine Möglichkeit geschaffen, diese Zertifikate im Admin-Panel hinzuzufügen. Navigieren Sie einfach zu Einstellungen > Sicherheit > SSL-Zertifikate, und dort finden Sie die Schaltfläche 'SSL-Zertifikat hinzufügen'. Im Dialogfeld können Sie wählen, ob Sie eine Zertifikatdatei hochladen oder den Zertifikatsinhalt direkt einfügen möchten.
🚨 Wichtig: Für bereits konfigurierte externe Verbindungen wie E-Mail wird die SSL-Verifizierung nicht automatisch aktiviert. Administratoren müssen alle konfigurierten Verbindungen überprüfen und die SSL-Verifizierung dort manuell aktivieren, wo dies erforderlich ist (z.B. bei öffentlich zugänglichen Diensten).
➡️ Erfahren Sie mehr in unserer Admin-Dokumentation.
Bitte beachten: Sie sollten bereits eine vorhandene benutzerdefinierte Zertifikatsdatei und/oder eine benutzerdefinierte CA-Zertifikatsdatei haben, die Sie zu Zammad hinzufügen möchten. Das Dateiformat .crt wird unterstützt, und das Zertifikatsformat muss PEM (Base64 ASCII) sein.
Apropos LDAP: Wir haben zuvor den Prozess erläutert, durch den Zammad 6.2 eine neue LDAP-Quelle mit Authentifizierungsanforderungen einrichtet. Was ist jedoch, wenn die LDAP-Konfiguration die Verwendung einer LDAPS (LDAP über SSL)-Verbindung untersagt?
Da wir dieses Szenario bei der Entwicklung von Zammad 6.2 voraussahen, haben wir eine alternative Lösung implementiert. Anstelle von SSL bietet Zammad 6.2 die Option STARTTLS als Verschlüsselungsmethode an. Jetzt können Sie zwischen verschiedenen Verschlüsselungstypen wählen, nämlich SSL und STARTTLS oder keinen von beiden, abhängig von Ihren spezifischen LDAP-Konfigurationsanforderungen.
➡️ Lesen Sie mehr über LDAP-Quellen in der Admin-Dokumentation.
Schneller Login auf allen Ihren Geräten und Systemen - das ist in Zammad schon lange über SAML möglich. Aber wir wollten uns nicht nur darauf beschränken. Indem wir diese leistungsstarke Synergie nutzen, haben wir die Fähigkeiten erweitert, die Konfiguration von signierten oder verschlüsselten Anfragen zu ermöglichen. Gedacht, getan - mit Zammad 6.2 können Sie nun festlegen, ob Sie möchten, dass Ihre Anfragen signiert, verschlüsselt, beides oder gar nicht sein sollen.
➡️ Erfahren Sie mehr in unserer Admin-Dokumentation.
Beim Arbeiten mit Zammad-Tickets kann es sehr praktisch sein, Informationen aus anderen Quellen abzurufen. Anstatt die ausgewählten Daten manuell in Zammad zu importieren/kopieren (und sich mit dem Kopfzerbrechen von Aktualisierungen an zwei Stellen herumzuschlagen), machen wir es Benutzern einfacher, eine entsprechende Entität aus externen Quellen auszuwählen.
Angenommen, Sie möchten Daten aus einer externen Produkt-Datenbank abrufen und so Ihre Produkte zu Tickets hinzufügen. Nun, in Zammad 6.2 haben wir für Sie einen Attributtyp namens 'External Data Source Field' eingeführt. Sobald die Verbindung zur Datenquelle hergestellt ist, können Sie nach Produkten suchen und diese aus einer Liste auswählen. Darüber hinaus haben Sie die Möglichkeit, einen Link zur Quelle zu erstellen, der in diesem Szenario die Produktwebsite wäre.
➡️ Lesen Sie alles über die Konfiguration externer Datenquellen in unserer Admin-Dokumentation.
Bitte beachten Sie: Derzeit wird nur GET als Anfragemethode unterstützt, und die Datenstruktur muss im JSON-Format vorliegen.
Kommunikationssysteme stellen ein enormes Reservoir an Daten dar, in dem sich kontinuierlich große Mengen von Nachrichten und Anhängen mit Informationen über Kunden, Mitarbeiter und IT-Systeme ansammeln. Dies bringt die Herausforderung mit sich, diese Daten in Übereinstimmung mit den gesetzlichen Aufbewahrungsrichtlinien effizient zu verwalten, was häufig manuelle Löschprozesse erfordert.
Mit Zammad 6.2 gehört dieser manuelle Vorgang der Vergangenheit an. Administratoren können nun einmalig Regeln aufstellen, die sich an den Datenschutz- und Aufbewahrungsrichtlinien ihres Unternehmens orientieren. Folglich werden Benutzerdaten oder andere Objektdaten, wie z. B. Tickets, nach einer bestimmten Zeit und unter bestimmten Bedingungen automatisch gelöscht, wobei eine Löschhistorie geführt wird.
Fragen Sie sich, wie das funktioniert? Wir haben das Auswahlfeld unseres Scheduler erweitert, indem wir zusätzliche Objekte hinzugefügt haben, darunter Tickets, Benutzer und Organisationen.
➡️ Lesen Sie alles darüber in der Admin-Dokumentation.
Achtung: Bitte verwenden Sie den Scheduler mit der Aktion: Sofort löschen und der Aktion: Einen Datenschutzlöschungsauftrag hinzufügen mit Vorsicht! Wenn sie ausgeführt werden, sind die Objekte gelöscht und es ist kein Rollback möglich.
Wenn wir schon von Daten sprechen: Die zunehmenden Mengen an Anhängen für Tickets und die Wissensdatenbank erfordern ausreichenden Speicherplatz. Standardmäßig überträgt Zammad sie in die Datenbank. Während wir für Instanzen mit höherer Last den Wechsel zum Dateisystemspeicher empfehlen, bietet Zammad auch eine dritte Option: Simple Storage (S3), ein Cloud-basierter Speicherdienst, der es Ihnen ermöglicht, Daten über das Internet zu speichern und abzurufen.
Um die Simple Storage (S3) zu verwenden, setzen Sie den "Speichermechanismus" in Zammad unter System in den Einstellungen auf Simple Storage (S3). Bevor Sie dies jedoch tun, ist es wichtig, die Verbindung zum Dienst in Zammad zu konfigurieren.
In unserer Admin-Dokumentation finden Sie eine umfassende Schritt-für-Schritt-Anleitung.
Standardmäßige SSL-Verifizierung im UserAgent
Das Standardverhalten von SSL in der UserAgent-Klasse von Zammad wurde geändert. Früher wurde keine SSL-Verifizierung durchgeführt, es sei denn, sie wurde explizit angefordert. Jetzt wird standardmäßig eine SSL-Verifizierung durchgeführt, es sei denn, sie wird explizit abgelehnt.
Dies kann auf Systemen mit benutzerdefinierten Addons, die die UserAgent-Klasse verwenden, um auf andere Systeme über HTTPS zuzugreifen, zu Problemen führen, wenn diese Systeme selbstsignierte Zertifikate verwenden. In solchen Fällen sollten diese Zertifikate oder die CA-Zertifikate, die für ihre Generierung verwendet wurden, über den neuen Bildschirm zur Verwaltung von SSL-Zertifikaten in Zammad hochgeladen werden. Alternativ kann der benutzerdefinierte Code angepasst werden, um verify_ssl: false an UserAgent Calls zu übergeben und das alte Verhalten wiederherzustellen.
Umgang mit übergroßen E-Mails
Die Bearbeitung von E-Mails, die die Größenbeschränkung überschreiten, wurde geändert. Früher würde Zammad eine Antwort senden und die E-Mails lokal in var/spool/oversized_email speichern (wenn die Einstellung postmaster_send_reject_if_mail_too_large auf true gesetzt ist). In diesem Fall wird kein Ticket erstellt.
Das neue Verhalten besteht darin, dass Zammad die Antwort wie zuvor sendet, aber keine Dateien mehr für diese E-Mails lokal erstellt – sie werden verworfen.
Reservierter Trennzeichen im Gruppennamen
Der doppelte Doppelpunkt (::) ist nun ein reserviertes Trennzeichen im Gruppennamen, um eine verschachtelte Struktur für komplexe Hierarchien zu erleichtern. Früher war es möglich, dieses Zeichen als Teil des Gruppennamens frei zu verwenden, aber jetzt ist dies verboten.
Auf bestehenden Systemen werden die Gruppennamen, die das jetzt reservierte Trennzeichen enthalten, während des Migrationsprozesses umbenannt. Sets von Doppelpunkten werden dabei durch einen Bindestrich (-) ersetzt.
Zusätzlich werden auch vorhandene benutzerdefinierte Gruppenobjektattribute mit den Namen name_last und parent_id umbenannt, indem ein Unterstrich davor (_name_last und _parent_id) hinzugefügt wird. Dies liegt daran, dass diese Attribute jetzt Teil des Gruppenmodells sind und dedizierte Tabellenspalten unter den reservierten Namen erfordern.
Unzulässige URL-Werte in Benutzernamen-Attributen
Textwerte, die gültigen URI-Adressen ähneln, sind nun in den Vor- und Nachnamenattributen von Benutzern nicht mehr erlaubt. Früher war es möglich, beliebigen Text in diesen Attributen zu speichern. Administratoren sollten diese Änderung beachten, da sie Auswirkungen auf vorhandene Benutzerdaten haben kann.
Es wird keine Migration für bestehende Benutzer bei einem Update auf Zammad 6.2 durchgeführt. Falls Benutzerdatensätze URLs in ihren Namensattributen enthalten, werden diese während späterer Updates bereinigt. Es ist keine manuelle Aktion des Administrators erforderlich, da das URI-Schema oder Protokoll automatisch von problematischen Werten entfernt wird.
Dokumentation
Die Administrator-Dokumentation unterstützt jetzt mehrere Sprachen (was bereits für die Benutzerdokumentation verfügbar war). Wir haben die übersetzten deutschen und serbischen Versionen veröffentlicht, die Sie hier (DE)und hier (SR) finden können. Wenn Sie zur Dokumentation und/oder Übersetzung beitragen möchten, werfen Sie bitte einen Blick auf unseren Beitragsteil in der Systemdokumentation.
Docker / Kubernetes-Images für ARM64
Mit Zammad 6.2 stehen Images für die Bereitstellung auf Docker / Kubernetes sowohl für traditionelle AMD64 als auch für moderne ARM64-Plattformen zur Verfügung.
Linux Distribution Support Changes
In Zukunft wird Zammad Binärpakete für die letzten beiden Stable-/Langzeit-Support-Versionen der unterstützten Linux-Distributionen bereitstellen, bis diese ihr End-of-Life erreichen oder die technischen Anforderungen für Zammad nicht mehr erfüllen können. Die Verwendung der letzten unterstützten Stable-/Langzeit-Support-Version wird generell empfohlen.
Zammad 6.2 wird keine Pakete für CentOS 7, Debian 10, Ubuntu 18.04 und SLES 12 bereitstellen. Benutzern dieser Distributionen wird empfohlen, auf neuere Versionen wie CentOS 8, Debian 12, Ubuntu 22.04 und SLES 15 zu aktualisieren.
Entfernung der Twitter/X-Integration
Aufgrund der unklaren Situation bezüglich der Twitter/X APIs erwägen wir, die Twitter/X Integration mit der Veröffentlichung von Zammad 7.0 zu entfernen. Bitte schauen Sie hier für weitere Informationen und Updates zu diesem Thema.
Hinweis auf MySQL Deprecation
Zammad soll unseren Nutzern eine sichere und stabile Plattform bieten, welche in ihrer Performance überzeugt. Dafür ist die Wahl der unterstützten Datenbanksysteme entscheidend. Nach langen Argumentationen und auf Basis unserer langjährigen Erfahrung haben wir entschieden, dass Zammad zukünftig nur noch PostgreSQL als Datenbank unterstützen wird. Diese Änderung wird aber erst mit Zammad 7.0 in Kraft treten.
Bis dahin empfehlen wir keine neuen Installationen mit MySQL/MariaDB. Bestehende Systeme werden weiter unterstützt, müssen aber bis zum Release von Zammad 7 auf PostgreSQL migriert werden. Dafür haben wir einen detaillierten Migrationsleitfaden bereitgestellt, mit dem bestehende Systeme kostenfrei auf PostgreSQL umgestellt werden können.
Diese Entscheidung ist uns nicht leicht gefallen. Wir sehen sie jedoch als notwendig an, denn wir möchten für euch weiterhin auf eine langfristige und zuverlässige Plattform bereitstellen und den Aufwand für alle dabei in Grenzen halten.
Slack Integration Deprecation
Ab Zammad Version 7.0 werden wir diese spezielle Slack-Integration nicht mehr unterstützen. Es wird empfohlen, stattdessen auf vordefinierte Webhooks, ein neues Feature von uns, umzusteigen. Bestehende Slack-Integrationen sollten manuell migriert werden, bevor diese Funktion eingestellt wird.
Unterstützung für Internet Explorer 11
Ab Zammad Version 7.0 wird der Internet Explorer 11 nicht mehr unterstützt.
Berechtigungen für Ticketstatus- und Prioritäts-REST-API
Mit dem 6.3 Release werden neue Berechtigungen für die Verwaltung von Ticketstatus und Prioritäten eingeführt. Der Zugriff auf die entsprechende REST-API wird nicht länger mit der Berechtigung "admin.object" möglich sein. Bestehende Rollen und/oder Zugriffstoken, die für diese spezifischen REST-API-Endpunkte verwendet werden, müssen aktualisiert werden, um die neuen Berechtigungen ("admin.ticket_state" und "admin.ticket_priority") einzuschließen.
Bitte beachten Sie, dass Sie die folgenden Browser-Voraussetzungen erfüllen müssen, um diese Version nutzen zu können:
ZAA-2023-04
ZAA-2023-05
ZAA-2023-06
ZAA-2023-07
ZAA-2023-08
Alle Verbesserungen finden Sie im Changelog.
Source code
Packages
Upgrade
Hier können Sie Informationen zum Aktualisieren Ihrer Zammad-Installation finden: