Kapitel 4. Administration

By clicking the link Agents, you get access to the agent management screen of OTRS (see figure below). Administrators can add, change or deactivate agent accounts. Furthermore they can also manage agent preferences, including the language and notification settings for the individual agent's interface.

Abbildung 4.2. Agenten-Verwaltung

To register an agent, click on the Add agent button, enter the required data and press the Submit button at the bottom of the screen, as shown in Figure.

Abbildung 4.3. Adding a new agent

Nachdem Sie einen neuen Benutzer angelegt haben, muss dieser einer Gruppe bzw. einer Rolle zugewiesen werden. Sie werden nach dem Anlegen eines neuen Benutzers automatisch auf die Bildschirmmaske für die Zuweisung eines Benutzers in Gruppen weitergeleitet. Weitere Informationen über Gruppen und Rollen finden Sie in den Abschnitten Gruppen und Rollen dieses Kapitels.

Every agent's account should belong to at least one group or role. In a brand new installation, there are three pre-defined groups available, as shown in Table 4-1.

You can access the group management page (see figure below) by clicking the Groups link in the admin area.

Abbildung 4.4. Gruppen-Verwaltung

To add an agent to a group, or to change the agents who belong to a group, you can use the link Agents <-> Groups from the Admin page (see figure below).

Abbildung 4.5. Agent <-> group management

An overview of all groups and agents in the system is displayed on this page. You can also use the available filters to find a specific entity. If you want to change the groups that an agent is a member of, just click on the agent's name (see figure below). To change the agents associated with a group, just click on the group you want to edit (see figure below).

Abbildung 4.6. Change the groups an agent belongs to

Abbildung 4.7. Change the agents that belong to a specific group

Each group has a set of rights associated with it, and each group member (agent) may have some combination of these rights for themselves. A list of the permissions / rights is shown in Table 4-2.

Nicht alle verfügbaren Berechtigungen werden standardmäßig angezeigt. Diese zusätzlichen Berechtigungen können hinzugefügt werden.

Rollen sind ein sehr mächtiges Feature in OTRS, um schnell und einfach die Vergabe von Zugriffsrechten für viele Benutzer vorzunehmen. Vor allem bei großen und komplexen Installationen mit vielen Benutzern, Gruppen und Queues, zahlt sich dieses Feature schnell aus und erspart dem OTRS-Administrator viel Zeit und Arbeit. Das nachfolgende Beispiel stellt ein mögliches Szenario vor.

Um den Nutzen von Rollen zu verdeutlichen, stellen Sie sich die Situation vor, dass Sie ein OTRS-System mit 100 Benutzern verwalten. 90 Benutzer haben Zugriff auf eine Queue namens Support, die mehrere themenspezifische Unter-Queues enthält und in der die Support-Anfragen Ihrer Kunden landen. Die restlichen Queues des Systems sind für die 90 Supporter nicht zugänglich, dies wurde durch Gruppenzugriffsrechte so festgelegt. Die übrigen 10 Benutzer haben Zugriff auf alle Queues im System. Sie sortieren falsch einsortierte Mails aus, behalten die "Raw"-Queue im Auge und verschieben Spam-Mails in die "Junk"-Queue.

Im Rahmen einer Unternehmensumstrukturierung wird eines Tages zusätzlich eine Abteilung eröffnet, die Produkte verkaufen soll. Es müssen Angebote, Auftragsbestätigungen und Rechnungen erstellt, Anfragen bearbeitet, Bestellungen ans Lager weitergeleitet und Stornierungen entgegen genommen werden. Ein Teil der bisherigen Mitarbeiter soll in verschiedenen Bereichen der neuen Abteilung tätig werden und Sie als OTRS-Administrator haben nun die Aufgabe die neuen Queues anzulegen, die erweiterten Zugriffsrechte anzupassen und diese für die einzelnen Benutzer zu ändern.

Da es mühsam und viel zu umständlich wäre, für einen Teil aller 100 Benutzer einzeln die Zugriffsrechte zu ändern, richten Sie Rollen ein die mit Hilfe von Gruppenberechtigungen die verschiedenen Zugriffsrechte regeln. Anschließend ändern Sie für die entsprechenden Benutzer auf einmal die Zugriffsberechtigungen, indem Sie diese der entsprechenden Rolle zuweisen. Beim Anlegen neuer Benutzer müssen Sie nicht mehr einzeln die Gruppen und Zugriffsrechte einstellen, auch hier genügt die Verknüpfung des neuen Benutzers mit einer Rolle.

You can access the role management section (see figure below) by clicking the Roles link on the Admin page.

Abbildung 4.8. Rollenverwaltung

An overview of all roles in the system is displayed. To edit a role's settings, click on the role's name. In a fresh new OTRS installation, there are no roles defined by default. To register one, click on the Add role button, provide the needed data and submit it (see figure below).

Abbildung 4.9. Adding a new role

To get an overview of all roles and agents in the system, click on the link Roles <-> Agents on the Admin page. You can also use filters to find a specific element. If you want to change the roles associated with an agent, just click on the agent's name (see figure below). To change the agents associated with a role, click on the role you want to edit (see figure below).

Abbildung 4.10. Change the roles associated with an agent

Abbildung 4.11. Change the agents associated with a specific role

Um eine Übersicht aller Rollen und Gruppen im System zu erhalten, verwenden Sie den Link "Rollen <-> Gruppen" im Administrationsbereich.

Abbildung 4.12. Manage roles-groups relations

To define the different access rights for a role, click on the name of a role or a group (see below the Figures 4.13 and 4.14, respectively).

Abbildung 4.13. Change group relations for a role

Abbildung 4.14. Change role relations for a group

OTRS supports different types of users. Using the link Customer Users (via the navigation bar, or the Admin page), you can manage the accounts of your customer users (see figure below), who can log into the system via the Customer Users interface (customer.pl). Through this interface, your customers can not only create tickets but also review their past tickets for new updates. It is important to know that a customer user is needed for the ticket history in the system.

Abbildung 4.15. Customer User management

You can search for a registered customer user, or edit their settings by clicking on their name. You also have the possibility to change the customer back-end, for further information please refer to the chapter about external back-ends.

To create a new customer user account, click on the Add customer user button (see figure below). Some of the fields are mandatory, i.e., they have to contain values, so if you leave one of those empty, it will be highlighted in red.

Abbildung 4.16. Adding a customer user

Customer Users can access the system by providing their username and password. The CustomerID is needed by the system to identify the user and associated tickets. Since the email address is a unique value, it can be used as the ID.

With the configuration parameter AdminCustomerUser::UseAutoComplete in the Admin SysConfig the autocomplete field can be activated for the customer ID selection in the customer user add or edit screen.

Customer users can be assigned to multiple customers (and vice-versa) using the link Customer Users ↔ Customers on the admin page. In addition to their own (primary) customer, they will be linked to any other customer for which there is a defined relation.

This gives them access to tickets of customer users from these customers.

Abbildung 4.17. Customer Users-Customers relations management

Customer users can also be added to a group, which can be useful if you want to add customer users of the same company with access to one or a few queues. First create the group to which your customer users will belong, via the Group management module. Then add the queues and select the new group for the queues.

The next step is to activate the customer group support. This can be done with the configuration parameter CustomerGroupSupport, from the Admin SysConfig option. Using the parameter CustomerGroupAlwaysGroups, you can specify the default groups for a newly added customer user, so that every new account will be automatically added to these groups.

Through the link Customer Users ↔ Groups you can manage which customer shall belong to the different groups (see figure below).

Abbildung 4.18. Customer Users-Group relations management

To define the different groups a customer should be part of and vice versa, click on the corresponding customer username or group (see below the Figures 4.18 and 4.19, respectively).

Abbildung 4.19. Change Group relations for a Customer User

Abbildung 4.20. Change Customer user relations for a Group

Customers can also be added to a group, which can be useful if you don't want to add group relations to every single customer user. First create the group to which your customers will belong, via the Group management module. Then add the queues and select the new group for the queues.

The next step is to activate the customer group support. This can be done with the configuration parameter CustomerGroupSupport, from the Admin SysConfig option. Using the parameter CustomerGroupAlwaysGroups, you can specify the default groups for a newly added customers, so that every new customer will be automatically added to these groups. Available permission levels can be changed via configuration.

Assigned permissions will be shared among all customer users of this customer, so permissions don't have to be given individually to every customer user (although this is still possible if required).

Different contexts of permission assignment are available, which will determine how the permissions are inherited by customer users.

The following contexts are available:

Through the link Customers ↔ Groups you can manage which customer shall belong to the different groups (see figure below).

Abbildung 4.21. Customers-Group relations management

To define the different groups a customer should be part of and vice versa, click on the corresponding customer username or group (see below the Figures 4.18 and 4.19, respectively).

Abbildung 4.22. Change Group relations for a Customer User

Abbildung 4.23. Change Customer user relations for a Group

Access to tickets on the customer interface with enabled group support is mostly evaluated by a combination of group and individual (customer/customer user based) permission. Only if both criteria are met, specific access is granted.

If the resulting access is rw, a customer user can view and modify a ticket, if the access is ro only viewing is possible.

For ticket creation only the group permissions are used and a customer user can create tickets for all queues with rw permissions (unless restricted otherwise, e.g. ACL or CustomerPanelOwnSelection).

Group permissions are additive (meaning that only one method needs to grant permissions) and the following possibilities are taken into account:

For the methods above, all customers related to a customer user are used. This includes the 'primary' customer (selected in Customer User admin frontend), additional customers (added in Customer Users ↔ Customers admin frontend) and other customer that might exist in the backend.

Individual permission checks require one of the following conditions to be met:

An example for the last item to clarify the functionality:

In this example we will create a multi-tier customer structure with resulting ticket permissions. To get the same results you will need a relatively clean system without many customizations.

First, create following customers through 'Admin → Customers' frontend:

Next, create the following customer users through Admin → Customer Users frontend and assign them to the already created customers. Use any valid email addresses for Email field.

Then, go to 'Admin → Groups' frontend and add the following as new groups:

Then, go to Admin → Queues and add corresponding queues which will use previously created groups. For the System address you can use any available.

Go to Admin → Customer Users ↔ Customers frontend and assign customer users to other customers.

Additionally, go to Admin → Customer Users ↔ Groups frontend and assign a single customer user direct access to a group.

Now, go to Admin → Customers ↔ Groups frontend and assign customers to groups according to the matrix below. Be sure to select proper permission level for each group and company.

For reference, please consult image below where all relationships are drawn as lines:

Finally, let's create some tickets. Go to New phone ticket frontend and create tickets, one each per customer user and queue (32 in total). By the way, this is possible in the agent frontend as the customer group restrictions are only active on the customer frontend.

For checking resulting access to the tickets, you can easily switch between the customer users by activating SwitchToCustomer option in SysConfig. Then just go to Admin → Customer Users and click on corresponding Switch to customer link next to the user's name.

You will be immediately logged in as that customer user and you can visit Tickets → Company Tickets screen for checking the ticket access. It should conform to the matrix below. Click on a ticket to check if corresponding permission level is honored: for ro permission level you should not see the Reply button.

This is the expected result for each customer user. The marker '{0}' refers to the location above where the corresponding setting was taken (this shows why the access is granted).

Resulting access for customer user Arvid Karlsson

Resulting access for customer user Barry Smith

Resulting access for customer user Christian Müller

Resulting access for customer user Diego Garcia

A salutation is a text module for a template. Salutations can be linked to one or more queues, as described in the section about queues. A salutation is used only if a ticket from a queue the salutation is linked to, is answered. To manage the different salutations of your system, use the "Salutations" link of the admin area (see figure below).

Abbildung 4.26. Verwaltung der Anreden

Nach einer Standardinstallation von OTRS sind bereits eine Anrede im System gespeichert, "system standard salutation (en)".

To create a new salutation, press the button Add salutation, provide the required data and submit it (see figure below).

Abbildung 4.27. Adding a new salutation

In Anreden können Variablen verwendet werden. Wenn Sie auf ein Ticket antworten, werden die Variablennamen durch die zugehörigen Werte ersetzt.

The different variables you can use in templates are listed in the lower part of the salutation screen. If you use, for example, the variable <OTRS_LAST_NAME> the last name of the ticket's sender will be included in your reply.

Another text module for a template is the signature. Signatures can be linked to a queue, as described in the section about the queues. Please note that a signature will only be appended to a template text, if it has previously been linked to a queue. You can manage the signatures in your system by accessing the "Signatures" link of the Admin page, (see figure below).

Abbildung 4.28. Signatures management

Nach einer Standardinstallation von OTRS ist bereits eine Signatur im System vorhanden, "system standard signature (en)".

To create a new signature, press the button Add signature, provide the needed data and submit it (see figure below).

Abbildung 4.29. Adding a new signature

Auch in Anreden und Signaturen können dynamische Inhalte eingebaut werden, wie etwa Vor- und Nachname des Agenten. Dies geschieht, genauso wie bei den Anreden, mit Hilfe verschiedener OTRS-Variablen, die in den Text der Signatur integriert werden können. Wenn Sie zum Beispiel die Variable lt;OTRS_LAST_NAME> in einer Signatur hinzufügen, wird der Name des Mitarbeiters angezeigt, der das Ticket beantwortet hat.

You can also optionally add one or more attachments to a template. If the template is selected, the attachments will be attached to the message composition window. If necessary, the agent can remove the attachment from an individual template before sending it to the customer.

Through the "Attachment" link of the Admin page, you can load the attachments into the database of the system (see figure below).

Abbildung 4.30. Attachments management

To create a new attachment, press the button Add attachment, provide the required data and submit it (see figure below).

Abbildung 4.31. Adding a new attachment

If an attachment is stored it can be linked to one or more templates. Click on the Attachment <-> Templates link of the Admin page (see figure below).

Abbildung 4.32. Anhänge zu Vorlagen zuordnen.

To associate different attachments with a specific template and vice versa, click on the corresponding template name or attachment (see below the Figures 4.29 and 4.30, respectively).

Abbildung 4.33. Anlagenzuordnungen einer Vorlage verändern

Abbildung 4.34. Vorlagen-Zuordnungen für einen Anhang verändern

To speed up ticket processing and to standardize the look of answers, you can define templates in OTRS. A template can be linked to one or more queues and vice versa.

There are different kind of templates that are used in different parts of OTRS and they have its own purpose, the following is the list of possible template types:

Answer templates can be accessed in two ways, from the ticket zoom screen in the article menu, or on a quicker way: from any ticket overview large screen such as Status View or Ticket View. For a fresh OTRS installation, the "empty answer" template (Answer) is set as the default for every queue.

As soon as Forward templates are added and assigned to queues, the "Forward" button in ticket zoom (that normally leads to a empty text forward screen) will change into a selection control, the selection is filled with the added Forward templates, by choosing one of the templates, the forward screen will be shown prefilled with the template text and attachments (similar to the reply selection box with the Answer templates).

Creating templates of type Create and PhoneCall will make visible the "Text Template" selection box in their respective screens, choosing a template for the list will populate the "Text" and "Attachment" fields (if available in the template). Notice that any previous change in the Text or attachments will be overwritten by selecting a template.

Clicking the "Templates" link on the Admin page brings you to the Template management screen (see figure below).

Abbildung 4.35. Template management

To create a new template, click on the Add template button, provide the required data (make sure to select the appropriate template type) and submit it (see figure below).

Abbildung 4.36. Adding a template

To add/remove templates to one or more queues, click on the "Templates <-> Queues" link on the Admin page (see figure below). You can also use filters to get information regarding a specific entity.

Abbildung 4.37. Template-Queue relations management

To define the different templates that will be available for a queue and vice versa, click on the corresponding template or queue (see below the Figures 5.32 and 5.33, respectively).

Abbildung 4.38. Ändern der Queue Zuordnung für eine Vorlage

Abbildung 4.39. Antwort-Zuordnungen einer Queue ändern

When choosing a template, additional information could be added to the template text, this depends on the template type:

PhoneCall and Create templates does not add any content to the template text, however New Email Ticket screen adds the queue assigned signature to the resulting email body (this screen has a separated box to visualize the signature).

Answer templates text when selected also included the salutation associated with the queue, then the text of the template, then the quoted ticket text, and finally the signature associated with the queue.

Die Weiterleiten Vorlagen sind ähnlich zu den Antwort Vorlagen, enthalten aber keine Anrede.

Since OTRS 6, a new button labeled Update all installed packages has been added to the sidebar of the package manager screen. When this button is pressed, an OTRS Daemon task will be scheduled to update all packages. Alternatively, this action can be also issued from the command line interface by using the Admin::Package::UpgradeAll console command.

Abbildung 4.73. Package Manager Update All Installed Packages Button

This feature reads the information of all defined package repositories and determines if there is a new version for every installed package in the system and calculates the correct order to update the packages respecting all other package dependencies, even if new versions of existing packages require new packages not yet installed in the system.

When the process to update all packages is running, a notification bar is added to the package manager screen for easier identification. When notification link is clicked, a progress summary is displayed with the current progress. Also, when the process is running package actions such as "Install", "Update", "Uninstall" and "ReInstall" some actions on the screen might be temporarily disabled in order to avoid conflicts.

Abbildung 4.74. Package Manager Update All Installed Packages In Progress Notification

When the process finishes (only if it was started in the graphical user interface) the progress notification will change to indicate the new state: it becomes green if all packages was correctly updated or red if there where any failures. Clicking on this notification will show the final summary. In the summary table, a tooltip for the status column of every package can indicate more details about the state. After closing this window, the package manager screen will refresh to show the new version of the installed packages.

Abbildung 4.75. Package Manager Update All Installed Packages Summary