<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!-- $Id: adminarea.xml,v 1.49 2012/02/23 12:52:55 mg Exp $ -->

<chapter id="adminarea">
<title>The ADMIN area of OTRS</title>

<section id="adminarea-general">
<title>Basics</title>

<para>
OTRS administrators use the Admin page on the OTRS web interface to configure the system - adding agents, customers and queues, ticket and mail settings, installing additional packages such as FAQ and ITSM, and much more.</para>

<para>
Agents who are members of the <emphasis>admin</emphasis> group can access the Admin area by clicking the <emphasis>Admin</emphasis> link in the navigation bar (see Figure below). The rest of the agents won't
see this link.
</para>

<para>
<screenshot>
<screeninfo>The OTRS Admin screen</screeninfo>
<graphic srccredit="Adminarea - screenshot" scale="40" fileref="screenshots/adminarea.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: OTRS Admin screen.</emphasis>
</para>

</section>

<section id="adminarea-agents-groups-and-roles">
<title>Agents, Groups and Roles</title>

<section id="adminarea-agents">
<title>Agents</title>

<para>
By clicking the link <emphasis>Agents</emphasis>, you get access to the agent management screen of OTRS (see Figure below). Administrators can add, change or deactivate agent accounts. Administrators can also manage agent preferences, for instance the language and notification settings for their interface.
</para>

<note>
<para>
An OTRS agent account may be deactivated but not deleted. Deactivation is done by setting the Valid flag to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
<screenshot>
<screeninfo>Agent management</screeninfo>
<graphic srccredit="Adminarea Agent management - screenshot" scale="40" fileref="screenshots/admin-agents.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Agent management.</emphasis>
</para>

<para>
To register an agent, click on the "Add agent" button, type all the needed data and press the Submit button at the bottom of the screen, as shown in Figure.
</para>

<para>
<screenshot>
<screeninfo>Adding an agent</screeninfo>
<graphic srccredit="Adminarea agent management - screenshot" scale="40" fileref="screenshots/add-agent.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new agent.</emphasis>
</para>

<para>
After the new agent account has been created, you should make the agent a member of one or more groups or roles. Information about groups and roles is available in the <link linkend="adminarea-groups">Groups</link> and <link linkend="adminarea-roles">Roles</link> sections of this chapter.
</para>

</section>

<section id="adminarea-groups">
<title>Groups</title>

<para>
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 5-1.
</para>

<para>
<table id="table-of-groups-after-installation">
<title>Default groups available on a fresh OTRS installation</title>
  <tgroup cols="2">
    <thead>
      <row>
        <entry>Group</entry>
        <entry>Description</entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>admin</entry>
        <entry>Allowed to perform administrative tasks in the system.</entry>
      </row>
      <row>
        <entry>stats</entry>
        <entry>
          Qualified to access the stats module of OTRS and generate statistics.
        </entry>
      </row>
      <row>
        <entry>users</entry>
        <entry>
          Agents should belong to this group, with read and write permissions. They can then access all functions of the ticket system.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>
</para>

<note>
<para>
In a brand new OTRS installation, the group <emphasis>users</emphasis> is initially empty. The agent 'root@localhost' belongs by default to the admin and stats groups.
</para>
</note>

<para>
You can access the group management page (see Figure below) by clicking the <emphasis>Groups</emphasis> link in the admin area.
</para>

<para>
<screenshot>
<screeninfo>Group management</screeninfo>
<graphic srccredit="Adminarea group management - screenshot" scale="40" fileref="screenshots/admin-groups.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Group management.</emphasis>
</para>

<note>
<para>
As with agents, an OTRS group may be deactivated but not deleted. Deactivation is done by setting the Valid flag to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
To add an agent to a group, or to change the agents who belong to a group, you can use the link <emphasis>Agents &lt;-&gt; Groups</emphasis> from the Admin page (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Agent Group management</screeninfo>
<graphic srccredit="Adminarea groups and agents - screenshot" scale="40" fileref="screenshots/admin-agents-and-groups.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Group management.</emphasis>
</para>

<para>
An overview of all groups and agents in the system is displayed. You can also use the filters to find a specific entity. If you want to change the groups that an agent is 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).
</para>

<para>
<screenshot>
<screeninfo>Agent-Group management</screeninfo>
<graphic srccredit="Adminarea groups and agents - screenshot" scale="40" fileref="screenshots/agent-group-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change the groups an agent belongs to.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Agent-Group management</screeninfo>
<graphic srccredit="Adminarea groups and agents - screenshot" scale="40" fileref="screenshots/agent-group-relations2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change the agents that belong to a specific group.</emphasis>
</para>

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

<para>
<table id="table-of-group-permissions-after-installation">
<title>Rights associated with OTRS Groups</title>
  <tgroup cols="2">
    <thead>
      <row>
        <entry>
          Right
        </entry>
        <entry>
          Description
        </entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>
          ro
        </entry>
        <entry>
          Read only access to the tickets, entries and queues of this group.
        </entry>
      </row>
      <row>
        <entry>
          move into
        </entry>
        <entry>
          Right to move tickets or entries between queues or areas that belong to this group.
        </entry>
      </row>
      <row>
        <entry>
          create
        </entry>
        <entry>
          Right to create tickets or entries in the queues or areas of this group.
        </entry>
      </row>
      <row>
        <entry>
          owner
        </entry>
        <entry>
          Right to update the owner of tickets or entries in queues or areas that belong to this group.
        </entry>
      </row>
      <row>
        <entry>
          priority
        </entry>
        <entry>
          Right to change the priority of tickets or entries in queues or areas that belong to this group.
        </entry>
      </row>
      <row>
        <entry>
          rw
        </entry>
        <entry>
          Full read and write access on tickets or entries in the queues or areas that belong to this group.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>
</para>

<note>
    <para>
        By default, the QueueView only lists tickets in queues that an agent has <emphasis>rw</emphasis> access to, i.e., the tickets the agent needs to work on. If you want to change this behaviour, you can set
        <link linkend="Ticket:Frontend::Agent::Ticket::ViewQueue:Ticket::Frontend::AgentTicketQueue_ViewAllPossibleTickets">
            Ticket::Frontend::AgentTicketQueue###ViewAllPossibleTickets
        </link>
        to <emphasis>Yes</emphasis>.
    </para>
</note>
</section>

<section id="adminarea-roles">
<title>Roles</title>

<para>
Roles are a powerful feature to manage the access rights of many agents in a very simple and quick manner. They are particularly applicable on large, complex support systems with a lot of agents, groups and queues. An example below explains when they may be used.
</para>

<para>
Suppose that you have a system with 100 agents, 90 of them with access to a single queue called "support" where all support requests are handled. The "support" queue contains some sub queues. The other 10 agents have permission to access all queues of the system. These 10 agents dispatch tickets, watch the raw queue and move spam messages into the "junk" queue.
</para>

<para>
The company now opens a new department that sells some products. Order request and acceptance, order confirmation, bills, etc. must be processed, and some of the company's agents shall do this via OTRS. The different agents have to get access to the new queues that must be created.
</para>

<para>
Because it would take a long time to change the access rights for the different agents manually, roles that define the different access levels can be created. The agents can then be added to one or more roles, with their rights automatically changed. If a new agent account is created, it is also possible to add this account to one or more roles.
</para>

<note>
<para>
Roles are really useful when maintaining larger OTRS installations. You should take care in their use though. Mixing Agent to Group with Agent to Role mappings can make for a complex access control scheme, difficult to understand and maintain. If you wish to use only roles and disable the Agents &lt;-&gt; Groups option in the Admin area, you can do so by modifying the <link  linkend="Framework:Frontend::Admin::ModuleRegistration:Frontend::Module_AdminUserGroup">Frontend::Module###AdminUserGroup</link> in the SysConfig. Be aware that this won't remove already existing Agents to Group assignments!
</para>
</note>

<para>
You can access the role management section (see Figure below ) by clicking the <emphasis>Roles</emphasis> link on the Admin page.
</para>

<para>
<screenshot>
<screeninfo>Role management</screeninfo>
<graphic srccredit="Adminarea roles - screenshot" scale="40" fileref="screenshots/admin-roles.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Role management.</emphasis>
</para>

<note>
<para>
As with agent and groups, roles once created can be deactivated but not deleted. To deactivate, set the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
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).
</para>

<para>
<screenshot>
<screeninfo>Role management</screeninfo>
<graphic srccredit="Adminarea roles - screenshot" scale="40" fileref="screenshots/add-role.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new role.</emphasis>
</para>

<para>
To get an overview of all roles and agents in the system, click on the link Roles &lt;-&gt; 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).
</para>

<para>
<screenshot>
<screeninfo>Agent Role management</screeninfo>
<graphic srccredit="Adminarea roles and agents - screenshot" scale="40" fileref="screenshots/admin-roles-agents-relation.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change the Roles associated with an Agent.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Agent Role management</screeninfo>
<graphic srccredit="Adminarea groups and agents - screenshot" scale="40" fileref="screenshots/admin-roles-agents-relation2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change the Agents associated with a specific Role.</emphasis>
</para>

<para>
To get an overview of all roles and groups in the system, click on the link Roles &lt;-&gt; Groups on the Admin page. You will see a similar screen as the one shown in the Figure. You can also use filters to find a specific entity.
</para>

<para>
<screenshot>
<screeninfo>Role Group management</screeninfo>
<graphic srccredit="Adminarea roles and groups - screenshot" scale="40" fileref="screenshots/admin-roles-groups.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Manage Roles-Groups relations.</emphasis>
</para>

<para>
To define the different access rights for a role, click on the name of a role or a group (see below the Figures 5.13 and 5.14, respectively).
</para>

<para>
<screenshot>
<screeninfo>Change Group relations for a Role</screeninfo>
<graphic srccredit="Adminarea roles and groups - screenshot" scale="40" fileref="screenshots/groups-roles-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Group relations for a Role.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Change Role relations for a Group</screeninfo>
<graphic srccredit="Adminarea roles and groups - screenshot" scale="40" fileref="screenshots/groups-roles-relations2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Role relations for a Group.</emphasis>
</para>

</section>

</section>

<section id="customers-and-groups">
<title>Customers and Customer Groups</title>

<section id="adminarea-customers">
<title>Customers</title>

<para>
OTRS supports different types of users. Using the link "Customers" (via the navigation bar, or the Admin page), you can manage the accounts of your customers (see Figure below), who can log into the system via the Customers interface (customer.pl). Through this interface, your customers can create tickets and access them as they are updated. It is important to know that a customer is needed for the ticket history in the system.
</para>

<para>
<screenshot>
<screeninfo>Customer management</screeninfo>
<graphic srccredit="Adminarea customer - screenshot" scale="40" fileref="screenshots/admin-customer.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Customer management.</emphasis>
</para>

<para>
You can search for a registered customer, 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 <link linkend="external-backends">external back-ends</link>.
</para>

<para>
To create a new customer account, click on the "Add customer" 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.
</para>

<para>
<screenshot>
<screeninfo>Customer management</screeninfo>
<graphic srccredit="Adminarea customer - screenshot" scale="40" fileref="screenshots/add-customer.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a customer.</emphasis>
</para>

<para>
Customers 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.
</para>

<note>
<para>
As with agents, groups and roles, customers can not be deleted from the system, only deactivated by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

</section>

<section id="adminarea-customers-groups">
<title>Customer Groups</title>

<para>
Customer users can also be added to a group, which can be useful if you want to add customers of the same company with access to one or a few queues. First create the group to which your customers will belong, via the <link linkend="adminarea-groups">Group management module</link>. Then add the <link linkend="adminarea-queue">queues</link> and select the new group for the queues.
</para>

<para>
The next step is to activate the customer group support. This can be done with the configuration parameter <link linkend="Framework:Frontend::Customer:CustomerGroupSupport">CustomerGroupSupport</link>, from the Admin SysConfig option. Using the parameter <link linkend="Framework:Frontend::Customer:CustomerGroupAlwaysGroups">CustomerGroupAlwaysGroups</link>, you can specify the default groups for a newly added customer, so that every new account will be automatically added to these groups.
</para>

<para>
Through the link "Customers &lt;-&gt; Groups" you can manage which customer shall belong to the different groups (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Customer Group management</screeninfo>
<graphic srccredit=">Adminarea customer groups - screenshot" scale="40" fileref="screenshots/admin-customer-groups.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Customer-Group relations management.</emphasis>
</para>

<para>
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 5.16 and 5.17, respectively).
</para>

<para>
<screenshot>
<screeninfo>Change Group relations for a Customer</screeninfo>
<graphic srccredit="Adminarea customers and groups - screenshot" scale="40" fileref="screenshots/groups-customers-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Group relations for a Customer.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Change Customer relations for a Group</screeninfo>
<graphic srccredit="Adminarea customer and groups - screenshot" scale="40" fileref="screenshots/groups-customers-relations2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Customer relations for a Group.</emphasis>
</para>

</section>

</section>

<section id="adminarea-queue">
<title>Queues</title>

<para>
Clicking on the link "Queues" of the Admin page, you can manage the <link linkend="what-is-a-queue">queues</link> of your system (see Figure below). In a new OTRS installation there are 4 default queues: Raw, Junk, Misc and Postmaster. All incoming messages will be stored in the "Raw" queue if no filter rules are defined. The "Junk" queue can be used to store spam messages.
</para>

<para>
<screenshot>
<screeninfo>Queue management</screeninfo>
<graphic srccredit="Adminarea queue - screenshot" scale="40" fileref="screenshots/admin-queue.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Queue management.</emphasis>
</para>

<para>
Here you can add queues (see Figure below) and modify them. You can specify the group that should use the queue. You can also set the queue as a sub-queue of an existing queue.
</para>

<para>
<screenshot>
<screeninfo>Queue management</screeninfo>
<graphic srccredit="Adminarea queue - screenshot" scale="40" fileref="screenshots/add-queue.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new queue.</emphasis>
</para>

<para>
You can define an unlock timeout for a queue - if an agent locks a ticket and does not close it before the unlock timeout has passed, the ticket will be automatically unlocked and made available for other agents to work on.
</para>

<para>
There are three escalation time settings that can be associated at queue level:
</para>

<itemizedlist>
    <title>Escalation - First Response Time</title>
    <listitem>
        <para>
After creation of the ticket, if the time defined here expires without any communication to the customer, either by email or phone, the ticket is escalated.
        </para>
    </listitem>
</itemizedlist>

<itemizedlist>
    <title>Escalation - Update Time</title>
    <listitem>
        <para>
If there is any customer followup via e-mail or the customer portal and recorded in the ticket, the escalation update time is reset. If there is no customer contact before the time defined here expires, the ticket is escalated.
        </para>
    </listitem>
</itemizedlist>

<itemizedlist>
    <title>Escalation - Solution Time</title>
    <listitem>
        <para>
If the ticket is not closed before the time defined here expires, the ticket is escalated.
        </para>
    </listitem>
</itemizedlist>

<para>
With 'Ticket lock after a follow-up', you can define if a ticket should be set to 'locked' to the old owner if a ticket that has been closed and later is re-opened. This ensures that a follow up for a ticket is processed by the agent that has previously handled that ticket.
</para>

<para>
The parameter for the system address specifies the email address that will be used for the outgoing tickets of this queue. There is also possibility to associate a queue with a salutation and a signature, for the email answers. For more detailed information, please refer to the sections <link linkend="adminarea-emailaddresses">email addresses</link>, <link linkend="adminarea-salutations">salutations</link> and <link linkend="adminarea-signatures">
signatures</link>.
</para>

<note>
<para>
As with agents, groups and customers, queues cannot be deleted, only deactivated, by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

</section>


<section id="adminarea-salutations-signatures-attachments-and-answers">
<title>Salutations, signatures, attachments and responses</title>

<section id="adminarea-salutations">
<title>Salutations</title>

<para>
A salutation is a text module for a response. Salutations can be linked to one or more queues, as described in the section about <link linkend="adminarea-queue">queues</link>. 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).
</para>

<para>
<screenshot>
<screeninfo>Salutation management</screeninfo>
<graphic srccredit="Adminarea salutation - screenshot" scale="40" fileref="screenshots/admin-salutation.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Salutation management.</emphasis>
</para>

<para>
After a default installation there is already one salutation available, "system standard salutation (en)".
</para>

<para>
To create a new salutation, press the button "Add salutation", provide the needed data and submit it (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Add a salutation</screeninfo>
<graphic srccredit="Adminarea salutation - screenshot" scale="40" fileref="screenshots/add-salutation.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new salutation.</emphasis>
</para>

<para>
It is possible to use variables in salutations. When you respond to a ticket, the variable names will be replaced by their values.
</para>

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

<note>
<para>
As with other OTRS entities, salutations cannot be deleted, only deactivated by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

</section>

<section id="adminarea-signatures">
<title>Signatures</title>

<para>
Another text module for a response is the signature. Signatures can be linked to a queue, as described in the section about the <link linkend="adminarea-queue">queues</link>. Only if a signature is linked to a queue will it be included into the response text. Through the "Signatures" link of the Admin page, you can manage the signatures in your system (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Management of Signatures</screeninfo>
<graphic srccredit="Adminarea Signatures - screenshot" scale="40" fileref="screenshots/admin-signatures.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Signatures management.</emphasis>
</para>

<para>
After a fresh installation of OTRS, there is one predefined signature stored in your system, "system standard signature (en)".
</para>

<para>
To create a new signature, press the button "Add signature", provide the needed data and submit it (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Add a signature</screeninfo>
<graphic srccredit="Adminarea signature - screenshot" scale="40" fileref="screenshots/add-signature.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new signature.</emphasis>
</para>

<para>
Like salutations, signatures can also contain dynamical content, such as the first and last name of the agent who answers the ticket. Here too, variables can be used to replace the content of the signature text for every ticket. See the lower part of the signatures screen for the variables which can be used. If you include the variable &lt;OTRS_LAST_NAME&gt; in a signature for example, the last name of the agent who answers the ticket will replace the variable.
</para>

<note>
<para>
As with salutations, signatures too cannot be deleted, only deactivated by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

</section>

<section id="adminarea-attachments">
<title>Attachments</title>

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

<para>
Through the "Attachment" link of the Admin page, you can load the attachments into the database of the system (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Managing Attachments for Responses</screeninfo>
<graphic srccredit="Adminarea attachment - screenshot" scale="40" fileref="screenshots/admin-attachment.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Attachments management.</emphasis>
</para>

<para>
To create a new attachment, press the button "Add attachment", provide the needed data and submit it (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Add an Attachment</screeninfo>
<graphic srccredit="Adminarea signature - screenshot" scale="40" fileref="screenshots/add-attachment.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a new attachment.</emphasis>
</para>

<para>
If an attachment is stored it can be linked to one or more responses. Click on the "Attachment &lt;-&gt; Responses"
link of the Admin page (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Linking Attachments to Responses</screeninfo>
<graphic srccredit="Adminarea attachment response - screenshot" scale="40" fileref="screenshots/admin-attachment-response.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Linking Attachments to Responses.</emphasis>
</para>

<para>
To associate different attachments with a specific response and vice versa, click on the corresponding response name or attachment (see below the Figures 5.27 and 5.28, respectively).
</para>

<para>
<screenshot>
<screeninfo>Change Attachment relations for a Response</screeninfo>
<graphic srccredit="Adminarea responses and attachments - screenshot" scale="40" fileref="screenshots/response-attachment-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Attachment relations for a Response.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Change Response relations for an Attachment</screeninfo>
<graphic srccredit="Adminarea responses and attachments - screenshot" scale="40" fileref="screenshots/response-attachment-relations2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Response relations for an Attachment.</emphasis>
</para>

</section>

<section id="adminarea-Responses">
<title>Responses</title>

<para>
To speed up the answering of tickets and to standardize the look of answers, you can define responses in OTRS. A response can be linked to one or more queues and vice versa. In order to be able to use a response quickly, the different responses are displayed below every ticket in the QueueView or in "My Queues".
</para>

<para>
On a fresh OTRS installation, the "empty answer" response is defined for every queue. Clicking the "Responses" link on the Admin page brings you to the Responses management page (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Responses</screeninfo>
<graphic srccredit="Adminarea response - screenshot" scale="40" fileref="screenshots/admin-response.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Responses management.</emphasis>
</para>

<para>
To create a new response, click on the "Add response" button, provide the required data and submit it (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Responses</screeninfo>
<graphic srccredit="Adminarea response - screenshot" scale="40" fileref="screenshots/add-response.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a response.</emphasis>
</para>

<para>
To add/remove responses to one or more queues, click on the "Responses &lt;-&gt; Queues" link on the Admin page (see Figure below). You can also use filters to get information on a specific entity.
</para>

<para>
<screenshot>
<screeninfo>Manage Response-Queue relations</screeninfo>
<graphic srccredit="Adminarea response queue - screenshot" scale="40" fileref="screenshots/admin-response-queue.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Response-Queue relations management.</emphasis>
</para>

<para>
To define the different responses that will be available for a queue and vice versa, click on the corresponding response or queue (see below the Figures 5.32 and 5.33, respectively).
</para>

<para>
<screenshot>
<screeninfo>Change Queue relations for a Response</screeninfo>
<graphic srccredit="Adminarea response and queue - screenshot" scale="40" fileref="screenshots/responses-queues-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Queue relations for a Response.</emphasis>
</para>

<para>
<screenshot>
<screeninfo>Change Response relations for a Queue</screeninfo>
<graphic srccredit="Adminarea response and queue - screenshot" scale="40" fileref="screenshots/responses-queues-relations2.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Response relations for a Queue.</emphasis>
</para>

<para>
The structure of a response is intuitive. It includes the salutation associated with the queue, then the text of the response, then the quoted ticket text, and finally the signature associated with the queue.
</para>

</section>

</section>

<section id="adminarea-auto-responses">
<title>Auto responses</title>

<para>
OTRS allows you to send automatic responses to customers on the occurence of certain events, such as the creation of a ticket in certain queue, reception of a follow-up message on a ticket, closure or rejection of a ticket, etc. To manage such responses, click the link "Auto responses" on the Admin page (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Auto Response management</screeninfo>
<graphic srccredit="Adminarea auto response - screenshot" scale="40" fileref="screenshots/admin-autoresponse.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Auto Response management.</emphasis>
</para>

<para>
To create an automatic response, click on the button "Add auto response", provide the needed data and submit it (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Adding an Auto Response</screeninfo>
<graphic srccredit="Adminarea auto response - screenshot" scale="40" fileref="screenshots/add-autoresponse.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding an Auto Response.</emphasis>
</para>

<para>
The subject and text of auto responses can be generated by variables, just as in signatures and salutations. If you insert, for example, the variable &lt;OTRS_CUSTOMER_EMAIL[5]&gt; into the body of the auto answer, the first 5 lines of the customer mail text will be inserted into the auto answer. You will find more details about the valid variables that can be used at the bottom of the screen shown in the Figure.
</para>

<para>
For every automatic answer, you can specify the event that should trigger it. The system events that are available
after a default installation are described in the Table 5-3.
</para>

<table id="table-of-autoanswer-types">
<title>Events for Auto answers</title>
  <tgroup cols="2">
    <thead>
      <row>
        <entry>
          Name
        </entry>
        <entry>
          Description
        </entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>
          auto reply
        </entry>
        <entry>
          Creation of a ticket in a certain queue.
        </entry>
      </row>
      <row>
        <entry>
          auto reply/new ticket
        </entry>
        <entry>
          Reopening of an already closed ticket, e.g. if a customer replies to such ticket.
        </entry>
      </row>
      <row>
        <entry>
          auto follow up
        </entry>
        <entry>
          Reception of a follow-up for a ticket.
        </entry>
      </row>
      <row>
        <entry>
          auto reject
        </entry>
        <entry>
          Automatic rejection of a ticket, done by the system.
        </entry>
      </row>
      <row>
        <entry>
          auto remove
        </entry>
        <entry>
          Deletion of a ticket, done by the system.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>

<note>
<para>
As with other OTRS entities, Auto responses too cannot be deleted, only deactivated, by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
To add an auto response to a queue, use the "Auto Response &lt;-&gt; Queues" link on the Admin page (see Figure below). All system events are listed for every queue, and an auto answer with the same event can be selected or removed via a listbox.
</para>

<para>
<screenshot>
<screeninfo>Manage Queue - Auto Response relations</screeninfo>
<graphic srccredit="Adminarea queue - auto response - screenshot" scale="40" fileref="screenshots/admin-autoresponse-queue.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Queue-Auto Response relations management.</emphasis>
</para>

<para>
To define the different auto responses that will be available for a queue, click on the corresponding queue name (see Figure below). It is also possible to edit an existing auto response - to do so, click on the reponse and edit in the same manner as editing a new auto response.
</para>

<para>
<screenshot>
<screeninfo>Change Auto Response relations for a Queue</screeninfo>
<graphic srccredit="Adminarea auto response and queue - screenshot" scale="40" fileref="screenshots/autoresponses-queues-relations.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Change Auto Response relations for a Queue.</emphasis>
</para>

</section>


<section id="adminarea-emailaddresses">
<title>Email addresses</title>

<para>
To enable OTRS to send emails, you need a valid email address to be used by the system. OTRS is capable of working with multiple email addresses, since many support installations need to use more than one. A queue can be linked to many email addresses, and vice versa. The address used for outgoing messages from a queue can be set when the queue is created. Use the "Email Addresses" link from the Admin page to manage all email addresses of the system (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Managing Email Addresses</screeninfo>
<graphic srccredit="Adminarea email - screenshot" scale="40" fileref="screenshots/admin-email.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: System Email Addresses management.</emphasis>
</para>

<para>
If you create a new mail address (see Figure below) you can select the queue or sub queue to be linked with it. This link enables the system to sort incoming messages via the address in the To: field of the mail into the right queue.
</para>

<para>
<screenshot>
<screeninfo>Adding a system Email Address</screeninfo>
<graphic srccredit="Adminarea email - screenshot" scale="40" fileref="screenshots/add-email.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Adding a system Email Address.</emphasis>
</para>

<note>
<para>
As with other OTRS entities, email addresses cannot be deleted, only deactivated by setting the Valid option to <emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

</section>

<section id="adminarea-notifications">
<title>Notifications</title>

<para>
OTRS allows notifications to be sent to agents and customers, on the occurence of certain events. Agents can set the system events for their own notifications via the <link linkend="user-preferences">preferences</link> link.
</para>

<para>
Through the "Agent Notifications" link on the Admin page, you can manage the notifications of your system (see Figure below). You can use filters to list only certain notifications.
</para>

<para>
<screenshot>
<screeninfo>Managing Notifications</screeninfo>
<graphic srccredit="Adminarea notifications - screenshot" scale="40" fileref="screenshots/admin-notification.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Notification management.</emphasis>
</para>

<para>
You can customize the subject and the text of the notifications. Click on the notification you want to change from the list, and its content will get loaded for editing (see Figure). Please note that there is a notification with the same name for each of the available languages.
</para>

<para>
<screenshot>
<screeninfo>Managing Notifications</screeninfo>
<graphic srccredit="Adminarea notifications - screenshot" scale="40" fileref="screenshots/customize-notification.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Customizing a Notification.</emphasis>
</para>

<para>
Just as with signatures and salutations, it is possible to dynamically create the content of a notification, by using special variables. You can find a list of variables at the bottom of the screen shown in the Figure.
</para>

<para>
It is also possible to create notifications based on events. You can specify in detail when and to whom you want such a notification to be sent. You can choose from a wide variety of parameters, such as: recipient group(s), agent(s), role(s), email address(es), type of event triggering the notification, ticket-type, state, priority, queue, lock, service, SLA, etc.
</para>

<para>
In order to see a list of all event based notifications, click on the link "Notifications (Event)" on the Admin page (see Figure).
</para>

<para>
<screenshot>
<screeninfo>Managing Event-based Notifications</screeninfo>
<graphic srccredit="Adminarea event based notifications - screenshot" scale="40" fileref="screenshots/admin-notification-eventbased.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Event based Notification management.</emphasis>
</para>

<para>
As shown in Figure, you can create a new notification by clicking on the Add button (see Figure).
</para>

<para>
<screenshot>
<screeninfo>Managing Event based Notifications</screeninfo>
<graphic srccredit="Adminarea event based notifications - screenshot" scale="40" fileref="screenshots/admin-notification-eventbased-new.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Registering an Event based Notification management.</emphasis>
</para>

<para>
Please note that the content of the event based notifications can also be dynamically created by using the special variables listed at the bottom of the screen shown in the Figure.
</para>

</section>

<section id="adminarea-smime">
<title>SMIME</title>

<para>
OTRS can process incoming S/MIME encoded messages and sign outgoing mails. Before this feature can be used, you need to activate it and change some <link linkend="Framework:Crypt::SMIME">config parameters</link> in the SysConfig.
</para>

<para>
The "S/MIME Certificates" link on the Admin page allows you to manage your S/MIME certificates (see Figure below). You can add or remove certificates, and also search through the SMIME data.
</para>

<para>
<screenshot>
<screeninfo>SMIME</screeninfo>
<graphic srccredit="Adminarea smime - screenshot" scale="40" fileref="screenshots/admin-smime.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: S/MIME management.</emphasis>
</para>

</section>

<section id="adminarea-pgp">
<title>PGP</title>

<para>
OTRS handles PGP keys, which allows you to encrypt/decrypt messages and to sign outgoing messages. Before this feature can be used, you need to activate it and change some <link linkend="Framework:Crypt::PGP"> config parameters </link> in the SysConfig.
</para>

<para>
Through the "PGP Keys" link on the Admin page, it is possible to manage the key ring of the user who shall be used for PGP with OTRS (see Figure below), e.g. the local OTRS user or the web server user. It is possible to add and remove keys and signatures, and you can search through all data in your key ring.
</para>

<para>
<screenshot>
<screeninfo>PGP</screeninfo>
<graphic srccredit="Adminarea pgp -  screenshot" scale="40" fileref="screenshots/admin-pgp.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: PGP management.</emphasis>
</para>

</section>

<section id="adminarea-status">
<title>States</title>

<para>
Through the "States" link on the Admin page, you can manage the different ticket states you want to use in the system (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Managing ticket states</screeninfo>
<graphic srccredit="Adminarea states - screenshot" scale="40" fileref="screenshots/admin-states.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: State management.</emphasis>
</para>

<para>
After a default setup, there are some states defined:
</para>

<itemizedlist>
  <listitem>
    <para>
        closed successful
    </para>
  </listitem>
  <listitem>
    <para>
        closed unsuccessful
    </para>
  </listitem>
  <listitem>
    <para>
        merged
    </para>
  </listitem>
  <listitem>
    <para>
        new
    </para>
  </listitem>
  <listitem>
    <para>
        open
    </para>
  </listitem>
  <listitem>
    <para>
        pending auto close+
    </para>
  </listitem>
  <listitem>
    <para>
        pending auto close-
    </para>
  </listitem>
  <listitem>
    <para>
        pending reminder
    </para>
  </listitem>
  <listitem>
    <para>
        removed
    </para>
  </listitem>
</itemizedlist>

<para>
Every state is linked to a type, which needs to be specified if a new state is created. By default the state types are:
</para>

<itemizedlist>
  <listitem>
    <para>
        closed
    </para>
  </listitem>
  <listitem>
    <para>
        merged
    </para>
  </listitem>
  <listitem>
    <para>
        new
    </para>
  </listitem>
  <listitem>
    <para>
        open
    </para>
  </listitem>
  <listitem>
    <para>
        pending auto
    </para>
  </listitem>
  <listitem>
    <para>
        pending reminder
    </para>
  </listitem>
  <listitem>
    <para>
        removed
    </para>
  </listitem>
</itemizedlist>

</section>


<section id="adminarea-sysconfig">
<title>SysConfig</title>

<para>
The SysConfig link leads to the section where many OTRS configuration options are maintained.
</para>

<para>
The SysConfig link on the Admin page loads the graphical interface for system configuration (see Figure below). You can upload your own configuration files for the system, as well as backup all your current settings into a file. Almost all configuration parameters of the OTRS framework and installed applications can be viewed and changed through this interface. Since all configuration parameters are sorted into groups and sub groups, it is possible to navigate quickly through the multitude of the parameters. It is also possible to perform a full-text search through all the configuration parameters.
</para>

<para>
<screenshot>
<screeninfo>The graphical interface for system configuration (SysConfig)</screeninfo>
<graphic srccredit="Adminarea sysconfig - screenshot" scale="40" fileref="screenshots/admin-sysconfig.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: The graphical interface for system configuration (SysConfig).</emphasis>
</para>

<para>
The graphical interface for system configuration is described in more detail in the chapter <link linkend="sysconfig">
"Configuring the system through the web interface"</link>.
</para>

</section>

<section id="adminarea-postmasterpop3-account">
<title>Using mail accounts</title>

<para>
There are several possibilities to transport new emails into the ticket system. One of them is the <link linkend="email-receiving-cmd">otrs.PostMaster.pl module</link> that pipes the mails directly into the system. Another possibility is the use of mail accounts which can be administrated through the web interface. The "PostMaster Mail Accounts" link on the Admin page loads the management console for the mail accounts (see Figure below). OTRS supports the mail protocols: POP3, POP3S, IMAP and IMAPS.
</para>

<para>
<screenshot>
<screeninfo>Mail account management</screeninfo>
<graphic srccredit="Adminarea postmaster - screenshot" scale="40" fileref="screenshots/admin-mailaccount.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Mail account management.</emphasis>
</para>

<para>
See the section about the <link linkend="email-receiving-pop3">PostMaster mail accounts</link> for more details.
</para>

</section>

<section id="adminarea-postmasterfilter">
<title>Filtering incoming messages</title>

<para>
OTRS has the capability to filter incoming messages, as reflected by incoming messages being sorted automatically into queues, or spam mails being moved into a specific queue. It is irrelevant whether  <filename>PostMaster.pl</filename> or mail accounts are used to get messages into the ticket system. Filter rules can be created through the link "PostMaster Filter" on the Admin page (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Managing filter rules for incoming messages</screeninfo>
<graphic srccredit="Adminarea postmasterfilter - screenshot" scale="40" fileref="screenshots/admin-postmasterfilter.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: PostMaster filter management.</emphasis>
</para>

<para>
A filter consists of one or more criteria that must match for the defined actions to be executed on the email. Filter criteria may be defined for the headers or the body of an email, e.g. search for specific header entries or strings in the body, even regular expressions are allowed. All actions for a filter rule are triggered by X-OTRS headers, which are inserted if the filter criteria match. The ticket system evaluates the inserted X-OTRS headers and executes the specific actions. X-OTRS headers can be used to sort an incoming message into a specific queue, change the priority of the message or ignore the message and not deliver it to the system. The Table 5-4 lists the different X-OTRS headers and their meaning.
</para>

<para>
Note: You also can use X-OTRS-FollowUp-* headers for follow up emails.
</para>

<table id="table-of-x-otrs-headers">
<title>Function of the different X-OTRS-headers</title>
  <tgroup cols="3">
    <thead>
      <row>
        <entry>
          Name
        </entry>
        <entry>
          Possible values
        </entry>
        <entry>
          Description
        </entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>
          X-OTRS-Priority:
        </entry>
        <entry>
          1 very low, 2 low, 3 normal, 4 high, 5 very high
        </entry>
        <entry>
          Sets the priority of a ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Queue:
        </entry>
        <entry>
          Name of a queue in the system.
        </entry>
        <entry>
          Sets the queue where the ticket shall be sorted. If set in X-OTRS header, all other filter rules that try to sort a ticket into a specific queue are ignored.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Lock:
        </entry>
        <entry>
            lock, unlock
        </entry>
        <entry>
          Sets the lock state of a ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Ignore:
        </entry>
        <entry>
          Yes or True
        </entry>
        <entry>
          If this X-OTRS header is set to "Yes", the incoming message will completely be ignored and never delivered to the system.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-State:
        </entry>
        <entry>
          new, open, closed successful, closed unsuccessful, ...
        </entry>
        <entry>
          Sets the next state of the ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-State-PendingTime:
        </entry>
        <entry>
         e. g. 2010-11-20 00:00:00
        </entry>
        <entry>
          Sets the pending time of a ticket (you also should sent a pending state via X-OTRS-State).
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Type:
        </entry>
        <entry>
         default (depends on your setup)
        </entry>
        <entry>
          Sets the type of a ticket (if Ticket::Type support is active).
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Service:
        </entry>
        <entry>
         (depends on your setup)
        </entry>
        <entry>
          Sets the service of a ticket (if Ticket::Service support is active).
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-SLA:
        </entry>
        <entry>
         (depends on your setup)
        </entry>
        <entry>
          Sets the SLA of a ticket (if Ticket::Service support is active).
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-CustomerUser:
        </entry>
        <entry>
          CustomerUser
        </entry>
        <entry>
          Sets the customer user for the ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-CustomerNo:
        </entry>
        <entry>
          CustomerNo
        </entry>
        <entry>
          Sets the customer ID for this ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-SenderType:
        </entry>
        <entry>
          agent, system, customer
        </entry>
        <entry>
          Sets the type of the ticket sender.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-ArticleType:
        </entry>
        <entry>
          email-external, email-internal, email-notification-ext, email-notification-int, phone, fax, sms, webrequest, note-internal, note-external, note-report
        </entry>
        <entry>
          Sets the article type for the incoming ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-DynamicField-&lt;DynamicFieldName&gt;:
        </entry>
        <entry>
          Depends on Dynamic Field configuration (Text: Notebook, Date: 2010-11-20 00:00:00, Integer: 1)
        </entry>
        <entry>
          Saves an additional info value for the ticket on &lt;DynamicFieldName&gt; Dynamic Field.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-Loop:
        </entry>
        <entry>
          True
        </entry>
        <entry>
          If this X-OTRS header is set, no auto answer is delivered to the sender of the message (mail loop protection).
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>

<para>
A name must be specified for every filter rule. Filter criteria can be specified in the section "Filter Condition". Choose via the listboxes for "Header 1", "Header 2" and so on for the parts of the messages where you would like to search, and specify on the right side the values you wish to filter on. In the section "Set Email Headers", you can choose the actions that are triggered if the filter rules match. You can select for "Header 1", "Header 2" and so on to select the X-OTRS-Header and set the associated values (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Addin filter rules for incoming messages</screeninfo>
<graphic srccredit="Adminarea postmasterfilter - screenshot" scale="40" fileref="screenshots/add-postmasterfilter.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Add a PostMaster filter.</emphasis>
</para>

<example id="sort-mails-into-junk">
<title>Sort spam mails into a specific queue</title>

<para>
A useful filter rule could be to let OTRS automatically move mails marked for spam with a spam detection tool such as SpamAssassin, into the "Junk" queue. SpamAssassin adds the "X-Spam-Flag" header to every checked mail. When the mail is marked as spam, the Header is set to "Yes". So the filter criteria would be "X-Spam-Flag: Yes". To create a filter rule with this criteria you can insert the name as, for example, "spam-mails". In the section for "Filter Condition", choose "X-Spam-Flag:" for "Header 1" from the listbox. Insert "Yes" as value for this header. Now the filter criteria is specified. To make sure that all spam mails get directed into the "Junk" queue, choose in the section for "Set Email Headers", the "X-OTRS-Queue:" entry for "Header 1". Specify "Junk" as value for this header. Finally add the new filter rule to activate it for new messages into the system.
</para>
</example>

<para>
There are additional modules, that can be used to <link linkend="email-receiving-filter">filter incoming messages</link> more specifically. These modules might be useful on larger, more complex systems.
</para>

</section>


<section id="adminarea-genericagent">
<title>Executing automated jobs with the GenericAgent</title>

<para>
The GenericAgent is a tool to execute tasks automatically. In its absence such tasks would need to be done by a human person, a real agent. The GenericAgent, for example, can close or move tickets, send notifications on escalated tickets, etc.
</para>

<para>
Click the link "GenericAgent" on the Admin page (see Figure below). A table with currently automated jobs is displayed which can be edited to switch to executing jobs manually, or removing them.
</para>

<para>
<screenshot>
<screeninfo>Job list for the GenericAgent</screeninfo>
<graphic srccredit="Adminarea genericagent - screenshot" scale="40" fileref="screenshots/admin-genericagent.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Job list for the GenericAgent.</emphasis>
</para>

<para>
Click the "Add job" button to create a new job. You first need to supply a name for the job, as also the times when the job should be executed. Different criteria to select the tickets to work on and the new properties of those tickets can also be set (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Creating a job for the GenericAgent</screeninfo>
<graphic srccredit="Adminarea genericagent - screenshot" scale="40" fileref="screenshots/add-genericagent-job.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Creating a job for the GenericAgent.</emphasis>
</para>

<para>
On completing the job creation, all affected tickets by the job are listed. This list helps you verify that the job has the expected behavior. No changes are made to these tickets yet. The job will actually be activated only when it is saved into the job list.
</para>

</section>

<section id="adminarea-adminemail">
<title>Admin email</title>

<para>
OTRS administrators can send messages to specific users or groups. The "Admin Notification" link on the Admin page opens the screen where the agents and groups that should be notified can be selected (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Admin notification</screeninfo>
<graphic srccredit="Adminarea email - screenshot" scale="40" fileref="screenshots/send-admin-notification.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Admin notification.</emphasis>
</para>

<para>
It is possible to specify the sender, subject and body text of the notification. You can also select the agents, groups and roles who should receive the message.
</para>

</section>

<section id="adminarea-session-management">
<title>Session management</title>

<para>
You can see all logged in users and their session details by clicking the "Session Management" link in the admin area (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Session management</screeninfo>
<graphic srccredit="Adminarea sessionmanagement - screenshot" scale="40" fileref="screenshots/admin-sessionmanagement.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Session management.</emphasis>
</para>

<para>
Some statistics about all active sessions are displayed, e.g. how many agents and customer users are logged in, number of active sessions. Any individual session can be removed by clicking on the <emphasis>Kill this session</emphasis> link on the right-hand side of the list. You also have the option to <emphasis>Kill all sessions</emphasis>, which can be useful if you'd like to bring the system down. Detailed information for every session is available, too (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>Session details</screeninfo>
<graphic srccredit="Adminarea session management - screenshot" scale="40" fileref="screenshots/admin-session-details.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Session details.</emphasis>
</para>

</section>

<section id="adminarea-system-log">
<title>System Log</title>

<para>
The "System Log" link on the Admin page shows the log entries of the system, reverse chronologically sorted with most recent first (see Figure below).
</para>

<para>
<screenshot>
<screeninfo>System Log</screeninfo>
<graphic srccredit="Adminarea syslog - screenshot" scale="40" fileref="screenshots/admin-syslog.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: System Log.</emphasis>
</para>

<para>
Each line in the log contains a time stamp, the log priority, the system component and the log entry itself.
</para>

<note>
<para>
System logs are available via the web interface only on Linux / Unix systems. On Windows systems, you can see the logs using a text editor and opening the file <filename>[install_dir]otrs\var\log\otrs.log</filename>.
</para>
</note>

</section>

<section id="adminarea-selectbox">
<title>SQL queries via the SQL box</title>

<para>
The "SQL Box" link on the Admin page opens a screen that lets you query the content of the tables in the OTRS database (see Figure below). It is not possible to change the content of the tables, only select queries are allowed.
</para>

<para>
<screenshot>
<screeninfo>SQL Box</screeninfo>
<graphic srccredit="Adminarea selectbox - screenshot" scale="40" fileref="screenshots/admin-selectbox.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: SQL Box.</emphasis>
</para>

</section>

<section id="adminarea-package-manager">
<title>Package Manager</title>

<para>
Using the "Package Manager" link on the Admin page, you can install and manage packages that extend the functionality of OTRS (see Figure below). See the <link linkend="application">Additional applications</link> section for a discussion on the extensions that are available from the OTRS repositories.
</para>

<para>
<screenshot>
<screeninfo>Package Manager</screeninfo>
<graphic srccredit="Adminarea packagemanager - screenshot" scale="40" fileref="screenshots/admin-packagemanager.png"></graphic>
</screenshot>
</para>

<para>
<emphasis>Figure: Package Manager.</emphasis>
</para>

<para>
The Package Manager shows the OTRS addon packages you currently have installed on your server, together with their version numbers.
</para>

<para>You can install packages from a remote host by selecting the repository in the <emphasis>Online Repository</emphasis> section, and clicking the <emphasis>Update repository information</emphasis> button. The available packages are displayed in the corresponding table. The right side of the screen shows the available packages. To install a package, click on <emphasis>Install</emphasis>. After installation, the package is displayed in the <emphasis>Local Repository</emphasis> section.
</para>

<para>
To upgrade an installed package, the list of available packages in the online repository will show <emphasis>Upgrade</emphasis> in the Action column for any package that has a higher version than the one locally installed. Just click Upgrade and it will install the upgrade on your system.
</para>

<para>
In some cases, such as when your OTRS system is not connected to the Internet, you can also install packages you have downloaded to a local disk. Click the <emphasis>Browse</emphasis> button on the Actions side bar, and select the .opm file on your disk. Click <emphasis>Open</emphasis> and then <emphasis>Install Package</emphasis>. After installation the package is displayed in the <emphasis>Local Repository</emphasis> section. You can use the same steps for updating a package that is already installed.
</para>

<para>
In special cases, you might want to configure the Package Manager, e.g., to use a proxy or to use a local repository. Just take a look at the available options in SysConfig under <link linkend="Framework:Core::Package">Framework:Core::Package</link>.
</para>

</section>

<section id="adminarea-webservices">
    <title>Web Services</title>
    <para>
        The Web Services link leads to the graphical interface where web services (for the OTRS
        Generic Interface) are created and maintained  (see Figure below).
    </para>
    <para>
        <screenshot>
            <screeninfo>The graphical interface for web services</screeninfo>
            <graphic srccredit="Adminarea webservices - screenshot" scale="40" fileref="screenshots/genericinterface-webservice-overview.png"></graphic>
        </screenshot>
    </para>
    <para>
        <emphasis>Figure: The graphical interface for web services.</emphasis>
    </para>
    <para>
        The graphical interface for web services configuration is described in more detail in the
        section <link linkend="webservice_gui">"Web Service Graphical Interface"</link>.
    </para>
</section>

<section id="adminarea-dynamicfields">
    <title>Dynamic Fields</title>
    <para>
        Dynamic Fields is the place where you setup an manage custom fields for tickets and
        articles (see figure below).
    </para>
    <para>
        <screenshot>
            <screeninfo>Dynamic fields overview screen</screeninfo>
            <graphic srccredit="Adminarea dynamicfields - screenshot" scale="40" fileref="screenshots/dynamicfields-overview-filled.png"></graphic>
        </screenshot>
    </para>
    <para>
        <emphasis>Figure: The dynamic fields overview screen with some dynamic fields.</emphasis>
    </para>
    <para>
        The dynamic fields configuration is described in more detail in the section
        <link linkend="dynamicfields-configuration">"Dynamic Fields Configuration"</link>.
    </para>
    <para>
        Each dynamic field type has its own configuration settings and therefore its own
        configuration screen.
    </para>
    <note>
        <para>
            In the OTRS framework, dynamic fields can only be linked to tickets and articles by default,
            but they can be extended to other objects as well.
        </para>
    </note>
</section>

</chapter>