Allgemeine Einstellungen
Nachfolgend finden Sie allgemeine und objektübergreifende Möglichkeiten der Systemkonfiguration von KIX.
Jeder geöffnete Tab, jede Ansicht, jede Suche usw. hat eine eindeutige URL, welche in der Adresszeile des Browsers angezeigt wird. Die URL wird bspw. in den Favoriten abgelegt, wenn ein Agent seine Suche speichert. Sie kann auch genutzt werden, um Tickets, Dialoge u.a.m. via URL-Direktaufruf zu öffnen oder um die ID eines Objekts zu ermitteln.
Direktaufruf via Browser URL
Anhand der Browser-URL kann jedes Objekt (Ticket, Kontakt, Organisation, Ansicht, Suche etc.) direkt aufgerufen werden. Zum Beispiel:
Aufruf des Tickets mit der ID "123": http://your.agentenportal.kix.cloud/tickets/123.
Aufruf des Dialogs "Neues Ticket": http://your.agentenportal.kix.cloud/tickets?new
Somit können Sie die URL aus der Adresszeile Ihres Browsers nutzen, um die aktuelle Ansicht in einem anderen Kontext wieder aufrufen. Beispielsweise, um die URL
per E-Mail an andere Agenten zu versenden
durch externe Anwendungen oder Dienste aufrufen zu lassen
als Hyperlink in ein Objekt-Info-Widget einbinden, sodass darüber bspw. eine Suche oder ein Objekt (z. B. der Kontakt) direkt aufgerufen werden kann.
ID anhand der URL ermitteln
Am Ende der Browser-URL finden Sie die ID des aktuell geöffneten Objekts (Kontakt/Organisation/Ticket usw.). Sie können diese ID nutzen, um direkt auf ein ganz bestimmtes Objekt zu referenzieren, z. B. in Platzhaltern, bei der Konfiguration von Rollen u.a.m.

Abb.: Die ID des aktuellen Objekts in der URL des Browsers
Konfigurationsschlüssel | ObjectHistoryTypes###Customer ObjectHistoryTypes###Orga |
Die Detailansicht von Kontakten und Organisationen enthält den Tab Historie. Hier ist ersichtlich, wer welche Änderungen am Kontakt bzw. an der Organisation vorgenommen hat. Protokolliert werden:
der Zeitpunkt der Änderung
der Nutzer, welcher die Änderung vorgenommen hat
die vorgenommene Änderung.
Wird eine Änderung vorgenommen, speichert KIX die am Objekt geänderten Parameter in Variablen und erstellt daraus einen String, welcher in der Historie in aufbereiteter Form als Kommentar ausgegeben wird: $1 geändert (alt: \"$2\", neu: \"$3\")
.
Variable | Wert |
---|---|
$1 | Attribut, welches geändert wurde |
$2 | alter Wert |
$3 | neuer Wert |
Diesen String können Sie nach Bedarf ändern, bspw. um Updates an einem Dynamischen Feld spezifisch auszugeben. Dies erfolgt im Menü
in den o. a. Konfigurationsschlüsseln.Es muss kein Eintrag für die einzelnen Attribut-Updates vorhanden sein. Es wird dann der Standard (Default) verwendet: <WHAT> changed (old: "<OLDVALUE>", new: "<NEWVALUE>"

Abb.: Konfiguration der Objekthistorie
Hinweis
Wenn Sie innerhalb des Strings doppelte Hochkommas verwenden, müssen diese mit vorangehendem Backslash maskiert werden (z. B. old: \"$2\"
). Alternativ können Sie einfache Hochkommas verwenden (z. B. old: '$2'
)
Soll für ausgewählte Nutzer die Historie nicht angezeigt werden, können Sie dies über die Berechtigungen der entsprechenden Rollen definieren. z. B. Rolle "Customer Reader":

Abb.: Rolle hat Leserechte auf Kontakte, aber keine Berechtigung auf die Kontakt-Historie
Konfigurationsschlüssel | Agentenportal: display-value-configuration Self Service Portal: ssp-display-value-configuration |
Sie können die Anzeigewerte folgender Objekte konfigurieren:
Organisation
Ticket
Kontakt
Asset (ConfigItem)
FAQ Artikel
Nutzer (User)
Damit können Sie festlegen, aus welchen Informationen sich die Label-Darstellungen der Objekte zusammensetzen. Diese Informationen können aus einer Kombination von alphanumerischen Zeichen und KIX Platzhaltern für Attributwerte und Dynamische Felder bestehen.
Somit können Sie:
das Label von Tickets individualisieren
den Anzeigewert eines Kontakts individualisieren
den Auswahlwert einer Organisation so anpassen, dass anstelle einer technischen Kundennummer der Wert eines Dynamischen Feldes angezeigt wird.
Voraussetzungen für dieses Beispiel:
Es muss ein Dynamisches Feld mit Objekttyp "Organisation" existieren.
Das Dynamische Feld muss in die Oberfläche der Organisation integriert sein.
SysConfig-Schlüssel:
(s. auch: Dynamische Felder in Dialogen bereitstellen )
Das Dynamische Feld sollte mit einem Wert belegt sein, damit dieser angezeigt wird.
Konfiguration
Die Konfiguration kann getrennt für das Agentenportal und das SSP vorgenommen werden.
Gehen Sie wie folgt vor:
Navigieren Sie im Explorer zu
Alternativ:
Navigieren Sie im Admin Modul des Agentenportals zu
Suchen und öffnen Sie den SysConfig-Schlüssel
bzw. .Im Schlüssel ist bereits das Pattern für das Objekt "Organisation" hinterlegt. Sie können es anpassen, um den Anzeigewert für die Organisation zu ändern.
Optional: Ergänzen Sie im Schlüssel weitere Objekte durch Angabe des Objekttyps (z. B. Kontakt) und konfigurieren Sie deren Pattern (s. auch Konfigurationsbeispiel).
Jedes Objekt muss in geschweiften Klammern angegeben sein. Mehrere Objekte werden durch Komma voneinander getrennt.
objectType: Das betreffende Objekt (z. B. Ticket, Organisation, Contact, ConfigItem, ConfigItem::Service, etc.)
pattern: Angabe einer Zeichenkette, welche den Anzeigetext bildet.
Die Zeichenkette muss in Hochkommas stehen
Die Zeichenkette kann aus einer Reihe von alphanumerischen Zeichen und KIX Platzhaltern bestehen:
Beispiel: "T#<KIX_TICKET_TicketNumber>: <KIX_TICKET_Title> (Status:<KIX_TICKET_State>)"
Beachten Sie, dass es nicht für alle Objekte Platzhalter gibt.
Speichern Sie Ihre Änderungen abschließend mit
.Klicken Sie im Header der SysConfig auf
, um die Ansicht im Frontend zu aktualisieren.
Konfigurationsbeispiel
Der Code im Beispiel zeigt die modifizierte Konfiguration der Anzeigewerte im Agentenportal.
{ "displayValues": [ { "objectType": "Organisation", "pattern": "<KIX_ORGANISATION_Name> (<KIX_ORG_DynamicField_DisplayValue>)" }, { "objectType": "Ticket", "pattern": "T#<KIX_TICKET_TicketNumber>: <KIX_TICKET_Title> (Status: <KIX_TICKET_State>)" }, { "objectType": "Contact", "pattern": "<KIX_CONTACT_Firstname> <KIX_CONTACT_Lastname> | <KIX_CONTACT_PrimaryOrganisation> (Kontakt ID: <KIX_CONTACT_ID>)" }, { "objectType": "ConfigItem", "pattern": "<KIX_ASSET_Name> (<KIX_ASSET_SectionGeneral_0_Type_0>)" }, { "objectType": "ConfigItem::Service", "pattern": "<KIX_ASSET_Name> (<KIX_ASSET_SectionGeneral_0_Type_0> # <KIX_ASSET_SectionGeneral_0_Criticality_0>)" }, { "objectType": "User", "pattern": "<KIX_USER_Firstname> <KIX_USER_Lastname> (<KIX_USER_UserLogin>) - <KIX_USER_DynamicField_Source>" } ], "id": "display-value-configuration", "name": "Display Value Configuration", "type": "Agent Portal", "valid": true, "application": "agent-portal" }
Konfigurationsschlüssel | agent-portal-configuration |
Bei Ausführung einer Suche wird das Widget mit den Suchkriterien zusammengeklappt, um mehr Platz für die Anzeige der Suchergebnisse zu erhalten. Sie können dieses Verhalten deaktivieren:
Navigieren Sie im Explorer zu
Suchen und öffnen Sie den SysConfig-Schlüssel
Suchen Sie den Parameter
minimizeSearchCriteriaWidget
.Dieser regelt das Verhalten des Widgets.
Zum Deaktivieren des Verhaltens setzen Sie den Wert des Parameters auf
false
.Zum Aktivieren des Verhaltens setzen Sie den Wert des Parameters auf
true
Default:
true
Abb.: Das Einklappen des Suchkriterien-Widgets aktivieren
Speichern Sie Ihre Eingaben abschließend mit
.Klicken Sie in der Übersicht auf
, um die Ansicht im Frontend zu aktualisieren.
Sie können sowohl die Dateitypen als auch die Dateigrößen für den Up- und Download von Dateien festlegen. Dazu stehen Ihnen nachfolgende SysConfig-Schlüssel, die Sie im Menü
konfigurieren können.Die Einstellungen haben Einfluss auf das Feld Attachment|Anhang im Ticket, Artikel, FAQ und Asset. Sie haben keinen Einfluss auf Dynamische Felder vom Typ "Anhang". Diese Einschränkungen werden direkt in der Konfiguration des Dynamischen Feldes vorgenommen.
Einschränkungen für Datei-Typen
FileUpload::AllowedContentTypes
Definiert die zulässigen Inhaltstypen für Datei-Uploads (Anhänge). Angabe als RegEx-Muster.
FileUpload::ForbiddenContentTypes
Definiert die verbotenen Inhaltstypen für Datei-Uploads (Anhänge). Angabe als RegEx-Muster.
Diese Option hat Vorrang vor FileUpload::AllowedContentTypes.
FileUpload::AllowedExtensions
Definiert die zulässigen Dateierweiterungen für Datei-Uploads (Anhänge). Angabe als RegEx-Muster.
FileUpload::ForbiddenExtensions
Definiert die verbotenen Dateierweiterungen für Datei-Uploads (Anhänge). Angabe als RegEx-Muster.
Diese Option hat Vorrang vor FileUpload::AllowedExtensions.
Einschränkungen für Dateigrößen
Sie können das Upload-Limit für Anhänge (kurzzeitig) anpassen, bspw. wenn Sie größere Dateien herunterladen möchten. Beachten Sie jedoch, dass damit die Serverlast erhöht wird!
Nachfolgende SysConfig-Schlüssel haben Einfluss auf:
Download von Anhängen für Tickets, Assets, FAQ
Download von Logfiles im Frontend
Up-/Download von Anhängen am FAQ Artikel
Download von Asset-Anhängen (Abgrenzung: Der Upload erfolgt weiterhin über den Frontendserver)
Hinweis für On-Premises-Systeme
Für die Socket-Kommunikation zwischen Browser und Frontend kann im Bedarfsfall die Umgebungsvariable SOCKET_MAX_HTTP_BUFFER_SIZE
angepasst werden. Wenden Sie sich dazu bitte an unseren Support.
API::Provider::Transport::MaxLenth
Maximal zulässige Größe des Requests aus der Anbieterkonfiguration (Angaben in Bytes).
Überschreibt den Standardwert.
Default: 52428800 Bytes
FileUpload::MaxAllowedSize
Legt die maximale Größe (in Bytes) für Datei-Uploads fest.
Default: 24000000 Bytes
Konfigurationsschlüssel | ObjectIcon::MaxAllowedSize |
Im v. g. Sys-Config-Schlüssel können Sie die maximale Dateigröße von Objekt-Icons (Avatare, Icons) für den Dateiupload begrenzen und damit Performanceprobleme unterbinden. Nutzer erhalten einen Hinweis, wenn die ausgewählte Datei den Wert überschreitet.
Die Konfiguration dieses Schlüssels wirkt sich für alle Objekt-Icons im System aus, z. B.:
Admin Modul > System > Icons (alle Icons, inkl. Firmen-Icon und Favicon)
Admi-Modul > Nutzerverwaltung > Nutzer (Avatar)
LDAP/AD-Synchronisation (Sync der Nutzer-Avatare)
Organisationen-Modul > Kontakt (Avatar)
Konfigurationsschlüssel |
|
Zur Eingabe von formatiertem Text (z. B. in Tickets oder Artikeln) verwendet KIX den CKEditor in Version 5. Bei Bedarf können Sie Anpassungen am Editor vornehmen. Die Anpassungen erfolgen getrennt für das Agentenportal und das Self Service Portal.
Navigieren Sie dazu ins Menü
und öffnen Sie einen der o. a. Konfigurationsschlüssel zur Bearbeitung.Informationen zu den Konfigurationsparametern finden Sie in der Dokumentation des CKEditors:
generelle CKEditor Dokumentation: https://ckeditor.com/docs/ckeditor5/latest/features/index.html
Anpassung der Toolbar: https://ckeditor.com/docs/ckeditor5/latest/getting-started/setup/toolbar.html#main-editor-toolbar
KIX ermöglicht die Anzeige wichtiger Daten und Größen im System und damit das Auffinden möglicher Fehlerquellen. Im Rahmen Ihres Supportvertrags oder nach expliziter Aufforderung können Sie diese Informationen direkt aus dem System heraus an unseren Support senden, damit unsere Mitarbeiter Sie bei der Analyse unterstützen können.
Support-Informationen anzeigen
Konsolenbefehl | Console::Command::Admin::SupportData::Collect |
Sie können sich die Support-Informationen in der KIX-Konsole anzeigen lassen, um diese zu analysieren.
Navigieren Sie im Admin Modul zum Menü
.Rufen Sie den Befehl Console::Command::Admin::SupportData::Collect auf.
Klicken Sie auf
.
Danach werden Ihnen die Supportdaten in der Konsole angezeigt. Dies kann je nach Datenmenge einen Augenblick dauern.
Support-Informationen versenden
Konsolenbefehl | Console::Command::Admin::SupportData::Collect --send |
KIX kann die Support-Informationen direkt aus dem System heraus an unser Support-Team senden, sodass wir Sie bei der Analyse unterstützen können. Voraussetzung dafür ist, dass Sie einen gültigen Support-Vertrag mit uns haben.
Wichtig
Versand nur nach vorheriger Absprache mit unserem Support!
Navigieren Sie im Admin Modul zum Menü
.Rufen Sie den Befehl Console::Command::Admin::SupportData::Collect auf.
Tragen Sie im Textfeld den Parameter
--send
ein.Klicken Sie auf
.
Danach werden die Support-Informationen an die im SysConfig-Schlüssel
hinterlegte E-Mail-Adresse gesendet.Support-Informationen automatisch versenden
Konfigurationsschlüssel | Daemon::SchedulerCronTaskManager::Task###SendSupportData |
Wenn Sie mit uns eine entsprechende vertragliche Vereinbarung haben, können Sie einen Cron-Job aktivieren, der den regelmäßigen Versand der Support-Informationen auslöst.
Wichtig
Aktivierung des Cron-Jobs nur nach vorheriger Absprache mit unserem Support!
Navigieren Sie zum Menü
.Suchen und öffnen Sie den Schlüssel
.Setzen Sie den Schlüssel auf "gültig".
Optional und in Absprache: Ändern Sie das Ausführungsintervall.
Initial erfolgt die Ausführung jeden Montag, 04:00 Uhr ( Schedule: "04" "1" ).
Speichern Sie die Änderung und klicken Sie abschließend auf
.
Danach versendet KIX die Support-Informationen in regelmäßigen Abständen an die im SysConfig-Schlüssel
hinterlegte E-Mail-Adresse.Empfängeradresse ändern
SysConfig-Schlüssel | SupportData |
Initial werden die Support-Informationen an die E-Mail-Adresse unseres Support Teams versendet (support@kixdesk.com). In Absprache mit unserem Support können Sie im SysConfig-Schlüssel
eine andere E-Mail-Adresse als Empfänger hinterlegen.Die angegebene E-Mail-Adresse wird sowohl vom Cron-Job als auch von der Konsole genutzt.
Der Aufruf der Ticketerstell-Maske kann aus externen Anwendungen oder Diensten heraus erfolgen. Dies erfolgt durch Aufruf der entsprechenden URL (z. B. http://localhost:20001/tickets?new). Werden der URL zusätzliche Parameter mitgegeben, kann sowohl der Kontakt am neuen Ticket gesetzt werden als auch die gewünschte Ticketvorlage gewählt werden.
Beispiel: Bei Annahme eines Anrufs ruft die Telefonanlage bzw. Telefon-Client die KIX-URL auf und gibt der URL die Informationen zum Anrufer mit. KIX kann diese Informationen auflösen und anhand derer die gewünschte Ticketvorlage öffnen und den entsprechenden Kontakt am neuen Ticket setzen.
Voraussetzung: Die Telefonanlage unterstützt den Aufruf von URLs.
Die URL für den Aufruf muss so aussehen:
KIX.Cloud: http://your.agentenportal.kix.cloud/tickets?new&from=0123456789&templateId=2
KIX On-Premises: http://localhost:20001/tickets?new&from=0123456789&templateId=2
Mehrere Parameter werden durch "&" aneinander gereiht.
Parameter | Beschreibung |
---|---|
from | Erwartet Informationen des Kontakts, z. B. die Telefonnummer. Startet eine Volltextsuche im Kontakt. Der identifizierte Kontakt wird am neu zu erstellenden Ticket eingetragen. Werden mehrere Kontakte gefunden, wird stets der erste gefundene Kontakt am Ticket eingetragen. Beispiel: http://localhost:20001/tickets?new&from=0123456789 Hinweise:
|
templateId | ID der Ticketvorlage, welche beim URL- Aufruf geladen wird. Beispiel: http://localhost:20001/tickets?new&from=0123456789&templateId=2 Tipp: Navigieren Sie zum Ermitteln der ID zum Menü Führen Sie den Mauszeiger über die gewünschte Vorlage und lesen Sie die ID in der Fußzeile des Browsers ab. |