<?xml version='1.0' encoding='ISO-8859-1'?>
<!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.22 2009/11/19 09:09:24 mb Exp $ -->

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

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

<para>
This is the central place for OTRS administrators. Here you can alter your
configuration, install additional packages such as FAQ and ITSM, add
queues and users, and much more.</para>

<para>
You start the Admin area by clicking the <emphasis>Admin</emphasis> link
in the navigation bar of the agent interface. The link is only displayed
if you are a member of the <emphasis>admin</emphasis> group. On a new
installation you can log in with the login
<emphasis>root@localhost</emphasis> and the password
<emphasis>root</emphasis>.
</para>

<warning>
<para>
Please change the password for this account as soon as possible via the

<link linkend="user-preferences">
user preferences
</link>

page, because this is a default password on OTRS systems.
</para>
</warning>

<para>
<screenshot>
<screeninfo>The admin area of OTRS</screeninfo>
<graphic srccredit="Adminarea - screenshot" scale="40" fileref="screenshots/adminarea.png"></graphic>
</screenshot>
</para>
</sect1>

<sect1 id="adminarea-user-groups-and-roles">
<title>Users, groups and roles</title>

<sect2 id="adminarea-user">
<title>Users</title>

<para>
Via the link <emphasis>Users</emphasis> you can enter the user management of
OTRS. Administrators can add, change or deactivate user accounts.
Administrators can also manage user preferences, for instance the language
of the user interface and notification settings for individual users.
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
user account. To deactivate an account set it to
<emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
<screenshot>
<screeninfo>User account management</screeninfo>
<graphic srccredit="Adminarea user management - screenshot" scale="40" fileref="screenshots/admin-users.png"></graphic>
</screenshot>
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
user account. To deactivate an account set it to
<emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
After you have created a new user you should make it a member of one or more
groups or roles. You will be redirected automatically to the screen for the
group and user management when you finished creating a user account.
</para>

</sect2>

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

<para>
Every user account should at least belong to one group or role. You can
access Group management via the <emphasis>groups</emphasis> link.
</para>

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

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
group. To deactivate a group set it to
<emphasis>invalid</emphasis> or <emphasis>invalid-temporarily</emphasis>.
</para>
</note>

<para>
After installation three pre-defined groups are available.
</para>

<para>
<table id="table-of-groups-after-installation">
<title>Default groups after OTRS has been installed</title>
  <tgroup cols="2">
    <thead>
      <row>
        <entry>
         Group
        </entry>
        <entry>
          Description
        </entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>
            admin
        </entry>
        <entry>
          Group for the users who should perform administrative tasks in the system.
          After the system has been installed only the user "root@localhost" is
          in this group.
        </entry>
      </row>
      <row>
        <entry>
          stats
        </entry>
        <entry>
          Users in this group may access the stats module of OTRS and
          generate statistics. After the system has been installed only
          "root@localhost" belongs to this group.
        </entry>
      </row>
      <row>
        <entry>
          users
        </entry>
        <entry>
          This is the group where your agents should belong to and have
          read and write access. If users are in this group and have write
          rights they can use all functions of the ticket system. After the
          system has been installed this group is empty.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>
</para>

<para>
To add a user to a group or to change the users inside a group you can use
the link <emphasis>Users &lt;-&gt; Groups</emphasis>.
</para>

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

<para>
An overview of all groups and users in the system is displayed in the lower
part of the screen. If you want to change the groups that a user is a member of just
click on the user name. To change the users that are part of a group just click on the
group you want to change.
</para>

<para>
Users can have different rights in a group. Below is a list of the
permission rights available:
</para>

<para>
<table id="table-of-group-permissions-after-installation">
<title>Rights in the user groups of OTRS</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 and entries or 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 groups.
        </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>

</sect2>
<note><para>By default, the QueueView only lists tickets in queues that an
agent has <emphasis>rw</emphasis> access to. The idea behind it is that the
QueueView lists only the tickets the agent needs to work on. If you'd like 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>


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

<para>
Roles are a very powerful and helpful feature to manage and change the
access rights of many users very simply and quickly. On big and complex
systems with many users, groups and queues this feature is very useful and
helps to save time.
</para>

<para>
To explain the advantages of the role feature imagine that you have a
system with 100 users. 90 users have access to a queue called "support"
that contains some sub queues. All support requests are handled through
this queue. All other queues of the system are not accessible for the 90
users. The other 10 users may access all queues of the system, they are not
restricted only to the support queue. they dispatch tickets, watch the raw
queue and move spam messages into the "junk" queue. Some day the company
opens a new department that sells products. Offerings, confirmations of
offerings, bills, e.g. must be created and some of the agents in your
system shall do this via OTRS. The different users have to get access to
the new queues that must be created. Because it would take a long time to
change the access rights for the different users manually, roles can be
created that define the different access levels. Then the users can be
added to one or more roles and the user rights get for this user accounts
get changed. If a new user 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
not use both User to Group and User to Role mappings at the same time though,
this would make maintenance really hard. Therefore, if you decide to go with
roles, we'd recommend you to to disable the Users &lt;-&gt; Groups option in
the Admin area by modifying the
<link linkend="Framework:front-end::Admin::ModuleRegistration:front-end::Module_AdminUserGroup">front-end::Admin::ModuleRegistration</link>
in SysConfig. Of course this would not remove already existing User to Group
assignments!</para>
</note>


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

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
role. To deactivate a role set it to "invalid" or
"invalid-temporarily".
</para>
</note>

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

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

<para>
To define the different access rights for a role the links
"Roles &lt;-&gt; Users" or "Roles &lt;-&gt; Groups" can be used.
</para>

</sect2>

</sect1>

<sect1 id="customer-user-and-groups">
<title>Customer users and customer groups</title>

<sect2 id="adminarea-customeruser">
<title>Customer users</title>

<para>
OTRS supports different types of users. Using the link "Customer Users"
used to manage accounts of your customers. A customer can log in the
system via the customer interface (customer.pl). The customer interface
enables your customers to access their own tickets as well as log new ones.
Also a customer user is needed for the ticket history in the system.
</para>

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

<para>
You can search for a specific customer user in the database and change the
customer user back-end. More information about customer user back-ends is available
in the chapter about


<link linkend="external-backends">
external back-ends
</link>.
</para>

<para>
You can create new customer user accounts. All input fields that are marked
with an asterisk (*) are mandatory and have to contain values. Very important is to
specify a account name and a password for the new user to enable that this
user can log in the system. Also you have to specify a customer ID
("Customer#"). This ID is needed by the system to identify the user and the
tickets of this user. For example the mail address of the user can be
specified for Customer#, because a mail address is a unique value for a user.
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
customer user. To deactivate a customer user account set it to
"invalid" or "invalid-temporarily".
</para>
</note>

</sect2>

<sect2 id="adminarea-customer-user-groups">
<title>Customer groups</title>

<para>
Customer users can also be added to a group. this feature might be useful,
if you want to add some customer users of the same company that shall only
have access to one or some queues through the customer interface. First
create via the


<link linkend="adminarea-groups">
group management module
</link>

the group, that shall contain all customer users of the company. Then
create the

<link linkend="adminarea-queue">
queues
</link>

and select the new group for this queues.
</para>

<para>
The next step is to activate the customer group support. This can be done
with the configuration parameter

<link linkend="Framework:front-end::Customer:CustomerGroupSupport">
CustomerGroupSupport
</link>

via the graphical configuration front-end of OTRS.
Using the parameter

<link linkend="Framework:front-end::Customer:CustomerGroupAlwaysGroups">
CustomerGroupAlwaysGroups
</link>

you can specify the groups for a new added customer user, the new account
will be added to this group automatically.
</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>
Through the link "Customer Users  &lt;-&gt; Groups" you can manage which
customer user shall belong to the different groups.
</para>

</sect2>

</sect1>

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

<para>
Through the link "Queue" you can manage the

<link linkend="what-is-a-queue">
queues
</link>

of your system. In a new installed system the "Junk", "Misc", "Postmaster"
and "Raw" queues already exist. "Raw" is the default queue, all
incoming messages will be stored in this queue if no filter rules are defined.
The "Junk" queue can be used to store spam messages.
</para>

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

<para>
Here you can add queues and modify them.
You can specify the name and the group that should use the queue.
You can also specify whether you want the new queue to be a sub-queue of
another already existing queue.
</para>

<para>
You can define an unlock timeout for this queue. If an agent locks a ticket and
does not close it before the unlock timeout has passed, the ticket will unlock
and will become available for other agents.
</para>

<para>
There are three escalation time settings at the queue level. For
'Escalation - First Response Time': if there is not added a customer
interaction, either email-external or phone, to a new ticket before the time
defined here expires, the ticket is escalated.
</para>

<para>
Escalation - Update Time: If there is an article added, such as a follow-up
via e-mail or the customer portal, the escalation update time is reset. If
there is no customer contact, either email-external or phone, added to a
ticket before the time defined here expires, the ticket is escalated.
</para>

<para>Escalation - Solution Time: If the ticket is not set to closed before
the time defined here expires, the ticket is escalated.
</para>

<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 set to closed
is re-opened. This ensures that a follow up for a ticket is processed by the
agent that has previously handled the same ticket.
</para>

<para>
The parameter for the system address sets the mail address that is used for
the outgoing tickets of this queue. With the salutation and signature
parameter the used values for the new queue can be selected. The sections


<link linkend="adminarea-emailaddresses">
email addresses
</link>


<link linkend="adminarea-salutations">
salutations
</link>

and

<link linkend="adminarea-signatures">
signatures
</link>

explaine these parameters in more detail.
</para>

<note>
<para>
To keep the consistency of the data in OTRS it is not possible to delete a
queue. To deactivate a queue set it to
"invalid" or "invalid-temporarily".
</para>
</note>

<para>
All configuration settings for new queues are also available for sub-queues.
</para>

</sect1>

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

<para>
To accelerate answering tickets and to standardize the look of answers you
can define responses in OTRS. A response can be linked to one or more
queues, a queue can be linked to one or more responses. To make it possible
to use a response quickly the different responses are displayed below of
every ticket in the QueueView or in "My Queues".
</para>

<para>
After a a default installation of the system the "empty answer" response is
defined for every queue. Through the "Responses" link it is possible to
manage the different responses.
</para>

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

<para>
<screenshot>
<screeninfo>Zuweisung einer Antwortvorlage zu einer Queue</screeninfo>
<graphic srccredit="Adminarea response queue - screenshot" scale="40" fileref="screenshots/admin-response-queue.png"></graphic>
</screenshot>
</para>

<para>
To add or remove response to one or more queues the "Responses &lt;-&gt; Queues"
link can be used.
</para>

<para>
If you use a response for example through the QueueView you can see, that
not only the text of the response and the ticket text is displayed but also
a salutation and a signature. A response is assembled by different text
modules. The signature and the salutation of the queue where the ticket is
stored are two of the text modules of the response and also the original
ticket text and, if defined, the text of the response is included. The
different text modules are ordered that first the salutation is displayed,
then the quoted ticket text then the text of the response and after all
these text modules the signature is shown.
</para>

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

<para>
A text module for a response is the salutation. Salutations can be linked
to one or more queues as described in the section about

<link linkend="adminarea-queue">
queues
</link>

. Only if a salutation is linked to a queue it is used if a ticket from
this queue is answered. The "Salutations" link lets you manage the
different salutations of your system.
</para>

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

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

<para>
Because the content of a salutation can be created dynamically, for example
for things that change for every ticket (e.g. the name or mail address of
the sender), it is possible to use variables in salutations. The text which
is saved in the variables will be placed in the response text if you reply
to a ticket.
</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 sender of the ticket will be
included in your reply.
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
salutation. To deactivate a salutation set it to
"invalid" or "invalid-temporarily".
</para>
</note>

</sect2>

<sect2 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 it will be included into the
response text. Through "Signatures" link you can manage the signatures in
your system.
</para>

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

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

<para>
Like salutations signatures also can contain dynamical content (e.g. the first and
last name of the agent who answers the ticket), also variables 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 be included in the signature
text.
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
signature. To deactivate a signature set it to
"invalid" or "invalid-temporarily".
</para>
</note>

</sect2>

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

<para>
Another optional part of a response can be one ore more attachments. The
attachment will be send if the response is used, but with checkboxes it is
possible to deactivate the attachment in the answer screen for tickets.
</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>
Through the "Attachment" link it is possible to load the attachments into
the database of the system. If an attachment is stored it can be linked to
one or more responses, just follow the "Attachment &lt;-&gt; Responses"
link.
</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>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
attachment. To deactivate a attachment set it to
"invalid" or "invalid-temporarily".
</para>
</note>

</sect2>

</sect1>

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

<para>
OTRS can send auto answers to customer users. Auto answers are send if
special events happen, e.g. if a new ticket is created in a queue, if a
follow-up for a ticket is received, if a ticket is closed or rejected by the
system. Through the link "Auto answers" the auto answers of the system can
be managed. If you create a auto answer you can select the event that
should trigger the auto answer. The following system events are available
after a default installation.
</para>

<para>
<screenshot>
<screeninfo>Verwaltung von automatischen Antworten</screeninfo>
<graphic srccredit="Adminarea auto response - screenshot" scale="40" fileref="screenshots/admin-autoresponse.png"></graphic>
</screenshot>
</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>
          This event is triggered if a new ticket in a queue is created.
        </entry>
      </row>
      <row>
        <entry>
          auto reply/new ticket
        </entry>
        <entry>
          This event is triggered if a already closed ticket with a new
          ticketnumber is reopened, e.g. if a customer replyes to such
          a ticket.
        </entry>
      </row>
      <row>
        <entry>
          auto follow up
        </entry>
        <entry>
          This event is triggered if a followup for a ticket is received by
          the system.
        </entry>
      </row>
      <row>
        <entry>
          auto reject
        </entry>
        <entry>
          This event is triggered if the system rejects a ticket
          automatically.
        </entry>
      </row>
      <row>
        <entry>
          auto remove
        </entry>
        <entry>
          This event is triggered if a ticket is removed by the system.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>

<para>
The subject and the text of auto answers can also be generated
by variables, like for signatures or salutations. If you insert the
variable &lt;OTRS_CUSTOMER_EMAIL[5]&gt; for example into the body of the
auto answer, the first 5 lines of the customer mail text is inserted into the
auto answer. See the lower part of the auto answer screen for more details
about the variables that can be used.
</para>

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
auto answer. To deactivate a auto answer set it to
"invalid" or "invalid-temporarily".
</para>
</note>

<para>
<screenshot>
<screeninfo>Adding an auto answer to a queue</screeninfo>
<graphic srccredit="Adminarea auto response queue - screenshot" scale="40" fileref="screenshots/admin-autoresponse-queue.png"></graphic>
</screenshot>
</para>

<para>
To add an auto answer to a queue follow the "Auto Answer &lt;-&gt; Queues"
link in the admin area. All system events are listed for every queue and a
auto answer with the same event can be selected or removed via a listbox.
</para>

</sect1>

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

<para>
To enable OTRS to send emails you need at least a valid email address used
by the system. Because many setups need more than one mail addresses OTRS is
able to work with many mail addresses at the same time. At least one mail
address can be specified for a queue, but it is also possible to specify
the same address for more than one queue. That means that more than one
address can be used to send mails from outside to a queue, but one address
has to be specified for the outgoing mails of a queue. The address, that
shall be used for outgoing messages of a queue, can be set if the queue is
created. Follow the "Email Addresses" link to manage all mail addresses of
the system.
</para>

<para>
<screenshot>
<screeninfo>Managing the mail addresses of the system</screeninfo>
<graphic srccredit="Adminarea email - screenshot" scale="40" fileref="screenshots/admin-email.png"></graphic>
</screenshot>
</para>

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

<note>
<para>
To keep the consistency of the data for OTRS it is not possible to delete a
mail address. To deactivate a mail address set it to
"invalid" or "invalid-temporarily".
</para>
</note>

</sect1>

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

<para>
Via their

<link linkend="user-preferences">
preferences
</link>

agents and customers can select the system events for notifications.
</para>

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

<para>
Through the "Notification" link in the adminarea you can manage the
notifications of your system. You can customize the subject and the text of
the notifications. Just select the notification you want to change from the
listbox and load the content of the notification via the "Change" button.
The name of the notification tells you for which language the notification
is used, which event triggers the notification and if the notification is
send to an agent or a customer.
</para>

<para>
Like signatures or salutation it is possible to create the content of a
notification dynamically by using special variables. In the lower part of the
notification screen you can find a list of all variables that can used for
notifications.
</para>

</sect1>

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

<para>
OTRS can process incoming S/MIME encoded messages. Also we
can 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>
<screenshot>
<screeninfo>SMIME</screeninfo>
<graphic srccredit="Adminarea smime - screenshot" scale="40" fileref="screenshots/admin-smime.png"></graphic>
</screenshot>
</para>

<para>
The "SMIME" link in the admin area of OTRS lets you manage your SMIME
certificates. You can add or remove certificates and search through the
SMIME data.
</para>

</sect1>

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

<para>
You can use OTRS to de- and encrypt messages with PGP. Also
you can 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>
<screenshot>
<screeninfo>PGP</screeninfo>
<graphic srccredit="Adminarea pgp -  screenshot" scale="40" fileref="screenshots/admin-pgp.png"></graphic>
</screenshot>
</para>

<para>
Through the "PGP" link in the admin area of OTRS it is possible to manage
the key ring of the user who shall be used for PGP with OTRS, 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>

</sect1>

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

<para>
Through the "Status" link in the admin area of OTRS you can manage the
different states you want to use in the ticket system.
</para>

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

<para>
After a default setup the states "closed successful",
"closed unsuccessful", "merged", "new", "open", "pending auto close+",
"pending auto close-" "pending reminder" and "removed" are already
installed in the system. Every state is linked to a state type that needs
to be specified if a new state is created. Per default the state types
"closed", "merged", "new", "open", "pending auto", "pending reminder" and
"removed".
</para>
</sect1>

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

<para>
The SysConfig is the place where many configuration options for OTRS are stored.
</para>

<para>
<screenshot>
<screeninfo>The graphical configuration front-end of OTRS (SysConfig)</screeninfo>
<graphic srccredit="Adminarea sysconfig - screenshot" scale="40" fileref="screenshots/admin-sysconfig.png"></graphic>
</screenshot>
</para>

<para>
The "SysConfig" link in the admin area of OTRS loads the graphical
configuration front-end. You can upload own config files for the system and
backup all your current settings into a file. Almost all config parameters
of the OTRS framework and the installed applications can be viewed and
changed through the web interface. Because all config parameters are sorted
into groups and sub groups it is possible to navigate quickly through the
multitude of the parameters. Also it is possible to perform a full-text
search through all the config parameters.
</para>

<para>
In the chapter

<link linkend="sysconfig">
"Configuring the system through the web interface"
</link>

the graphical configuration front-end is described in more detail.
</para>

</sect1>

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

<para>
There are several possibilities to transport new emails into the ticket
system. One possibility is the

<link linkend="email-receiving-cmd">
PostMaster.pl module
</link>

that pipes the mails directly into the system. Another possibility are mail
accounts which can be administrated through the web interface. The
"PostMaster Mail Account" link in the admin area of OTRS loads the
management console for the mail accounts. OTRS supports the mail
protocols POP3, POP3S, IMAP and IMAPS.
</para>

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

<para>
See the section about the

<link linkend="email-receiving-pop3">
PostMaster mail accounts
</link>

for more details.
</para>
</sect1>

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

<para>
Because incoming messages can be sorted automatically into queues or spam
mails can be moved into a specific queue, OTRS has the possibility to
filter incoming messages. It does not matter, if mail accounts are used, or if
<filename>PostMaster.pl</filename> is used to get messages into the ticket system. Filter
rules can be created through the link "PostMaster Filter" in the admin area
of OTRS.
</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>
A filter rule consists of one or more filter criteria that must match if
the filter rule shall be executed and one or more actions that are
executed, if the filter criteria match. You can define filter
criteria 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 deliver
it not to the system. The following table 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 in. Is a queue
          set by a 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>
          Is this X-OTRS header set to "Yes", the incomming 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. 2007-03-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-ArticleKey(1|2|3):
        </entry>
        <entry>
          Additional info key for the article.
        </entry>
        <entry>
          Saves an additional info key for this article.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-ArticleValue(1|2|3):
        </entry>
        <entry>
          Additional info value for the article.
        </entry>
        <entry>
          Saves an additional info value for the article.
        </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-TicketKey(1|2|...|8):
        </entry>
        <entry>
          Additional info key for the ticket.
        </entry>
        <entry>
          Saves an additional info key for the ticket.
        </entry>
      </row>
      <row>
        <entry>
          X-OTRS-TicketValue(1|2|...|8):
        </entry>
        <entry>
          Additional info value for the ticket.
        </entry>
        <entry>
          Saves an additional info value for the ticket.
        </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. In the section for "Match"
the filter criteria can be specified. Choose via the listboxes for
"Header 1", "Header 2" and so on the parts of the messages where you would
like to search and specify via the input files on the right sides the
values. In the section for "Set" you can choose the actions that are
triggered, if the filter rules match. You can select for "Header 1",
"Header 2" and so on the X-OTRS-Header and set the values.
</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 sort mails marked for
spam with a spam detection tool such as SpamAssassin into the "Junk" queue automatically.
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 for example "spam-mails". Also choose in the section for
"Match" for "Header 1" from the listbox "X-Spam-Flag:". Insert "Yes" as
value for this header. Now the filter criteria is specified. To make sure,
that all spam mails get sorted into the "Junk" queue choose in the section for
"Set" for "Header 1" the "X-OTRS-Queue:" entry. Specify "Junk" as value for
this header. Finally add the new filter rule to activate it for the next
new messages in 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 bigger and more complex
systems.
</para>

</sect1>

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

<para>
The GenericAgent is a tool to execute tasks automatically that otherwise
should be done
by a human person, a real agent. The GenericAgent for example can
close or move tickets, send notifications on escalated tickets, e.g.
</para>

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

<para>
To create a new job for the GenericAgent the link "GenericAgent" in the
admin area of OTRS can be used. A table with the already created jobs is
displayed where jobs can be executed manually or be removed. To create a new
job a name must be specified and the "Add" button must be pressed.
</para>

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

<para>
Via the screen for the creation of a new job for the GenericAgent the times
can be specified when the job shall be executed. Also different criteria
can be specified to select the tickets that shall be affected by the job.
Also it is possible to set the new properties of the tickets which are
affected by the new job.
</para>

<para>
If the creation of the job is finished all tickets are listed, that are
affected by the job. This list of tickets let you control if the job
works right, no changes are made to these tickets yet. The job will be
really activated if it is saved into the job list.
</para>

</sect1>

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

<para>
OTRS administrators can send messages to specific users or user groups.
The "Admin Notification" link opens the screen where the users and groups
can be selected that should be notified by the admin.
</para>

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

<para>
The sender, the subject and the message text of the notification can be
specified via the admin notification screen. Also the users and groups who
should receive the message can be selected from the table.
</para>

</sect1>

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

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

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

<para>
Some statistics about all active sessions are displayed, e.g. how
many agents and customer users are logged in, and how many sessions there are.
You have the option to <emphasis>Kill all sessions</emphasis> which can be
useful if you would like to bring the system down.
Also detailed information for every session is
available. Every individual session can be removed separately by clicking on
the <emphasis>x</emphasis> in the right-hand side of the session list.
</para>

</sect1>

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

<para>
The "System Log" link in the admin area of OTRS shows the last log entries
of the system.
</para>

<para>
<screenshot>
<screeninfo>System Log</screeninfo>
<graphic srccredit="Adminarea syslog - screenshot" scale="40" fileref="screenshots/admin-syslog.png"></graphic>
</screenshot>
</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>
The system logs are only available via the web interface on linux or
unix systems. On Windows systems you can see the log by opening the file
<filename>[install_dir]otrs\var\log\otrs.log</filename> with a text editor.
</para>
</note>


</sect1>

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

<para>
The "SQL Box" link opens a screen that lets you query the content of the
tables in the OTRS database. It is not possible to change the content of
the
tables, only queries are allowed.
</para>

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

</sect1>

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

<para>
With the Package Manager you can install  and manage packages that extend the
functionality of OTRS. 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>
In the package manager you can review the packages you currently have installed
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</emphasis> button. The right side of the screen shows
the available packages. You can install a package by clicking on the
<emphasis>Install</emphasis> button.
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 installed locally. Just click Upgrade and it will
install the package 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 next to the
<emphasis>Package</emphasis> field and select the .opm file on your disk.
Click <emphasis>Open</emphasis> and then <emphasis>Install</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, for instance
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>

</sect1>

</chapter>