Anpassungen in der Benutzeroberfläche

Während die Beispiele eben direkt in das Verhalten von OTRS eingreifen, verbessern angepasste Oberflächen-Funktionen die Benutzerinteraktion erheblich. Insbesondere die Agenten profitieren von der am lokalen Bedarf ausgerichteten Weboberfläche. Dabei lässt sich die Eigenschaft von OTRS nutzen, alle Informationen zu einem Bearbeitungsvorgang über das Webinterface wahlweise mit »POST«- oder »GET«-Variablen bereitzustellen. Da OTRS alle Aktionen über ein sehr fein granulares Rechtekonzept absichert, erzeugt dies auch kein konkretes Sicherheitsproblem. Das System prüft jede Aktion vorab - das heißt innerhalb eines jeden aufgerufenen Moduls - auf Zulässigkeit.

Ein Beispiel für eine veränderte Oberfläche ergab sich aus einer weiteren Anforderung im Service Desk: Die Mitarbeiter müssen oft ihre Zuständigkeit (als Besitzer oder Verantwortlicher) für ein Ticket einfacher beenden können als out of the Box vorgesehen. Technisch erfolgt dies durch Rückgabe der Zuständigkeit an das System (OTRS-Root). Als Frontend ist dafür ein Formular vorgesehen, das den neuen Besitzer sowie Betreff und Beschreibung abfragt. Für Agenten, die es oft ausfüllen und absenden müssen, ist das eine lästige und fehlerträchtige Angelegenheit.

Die OTRS-Admins haben die Oberfläche nun so angepasst, dass das Gleiche mit einem Mausklick erledigt ist. Der Vorgang lässt sich nämlich vollständig über eine URL abwickeln. Diese URL ist durch Analyse des bereitgestellten Dialogs (eines HTML-Formulars) rasch bestimmt, die entsprechenden Formularattribute sind dann in einen GET-Request schnell übernommen. Dazu lässt sich entweder der HTML-Quellcode direkt untersuchen oder, etwas komfortabler, ein Browser-Plugin zu Rate ziehen, beispielsweise Web Developer für den Firefox (Abbildung 3). Der gefundene Request, um bei einem vorhandenen Ticket den Besitzer auf »root« zu setzen, sieht so aus:

https://otrsserver/otrs/index.pl?Action=AgentTicketOwner&Subaction=Store&TicketID=11948&NewOwnerID=1&Subject=Freigabe%20Besitzer&ArticleTypeID=9&Body=Besitzer%20zurueckgesetzt%20von%20stefan%20auf%20root

Die Attribute »Subject« und »Body« sind frei wählbar. Die »TicketID« bezieht sich auf das aktuelle Ticket, Root hat immer die ID 1. Die URL lässt sich zum Testen direkt im Browser eingeben.

Abbildung 3: Das Firefox-Plugin Web Developer hilft die URL-Parameter im OTRS-Formular zu finden.

Frei konfigurierbare Templates

Nun wäre es sicher alles andere als komfortabel, immer eine derart angepasste URL eintippen zu müssen. Da das OTRS-GUI sowieso im Browser läuft, bietet es sich an, einen entsprechenden Link in die Weboberfläche einzubetten. OTRS definiert Oberflächen über spezielle Templates in einer eigenen DTL-Syntax (Dynamic Template Language). Die frei konfigurierbaren Templates liegen als Dateien unter »OTRS-Pfad/Kernel/Output/HTML/Themes«, wobei »Themes« beliebig benannte Ordner sind.

Die OTRS-Standardtemplates finden sich im Ordner »Standard«. Nun steht der Entwickler vor der Grundsatzentscheidung, wo er seine Modifikationen unterbringt. OTRS empfiehlt ein eigenes Template anzulegen, da jedes Update die Standardtemplates potenziell überschreibt. Allerdings bringt das Verfahren auch einen gravierenden Nachteil: Wenn ein OTRS-Update auch die Standardtemplates verbessert, beispielsweise um neue Funktionen, muss der Admin diese stets in den eigenen Templates nachziehen.

Aus diesem Grund scheint es sinnvoll, entgegen der Herstellerempfehlung direkt die Standardtemplates zu modifizieren. Da die gleich besprochenen Anpassungen auch das Standardverhalten von OTRS in den Perl-Modulen betreffen, die man nach Releasewechseln sowieso immer nachziehen muss, hat das Uni-Rechenzentrum den Weg modifizierter Standardtemplates gewählt, alle Modifikationen kamen folglich in den Ordner »OTRS-Pfad/Kernel/Output/HTML/Standard«.