<?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.12 2006/04/29 22:14:53 ck Exp $ -->

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

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

<para>
The admin area of OTRS is the central part in the web interface for the
OTRS administrator. All important settings for the system can be done,
changed and viewed via this module.
</para>

<para>
The admin area is reachable via the "Admin" link in the navbar of the agent
interface. The link is only displayed, if you are logged in as OTRS
administrator or if you are a member of the admin group. After a default
installation you can log in as OTRS admin with the username root@localhost
and the passworr root.
</para>

<warning>
<para>
Please change this password as fast as possible via the

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

page, because this password is set per default on new 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>User, groups and roles</title>

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

<para>
Via the link "User" the user management of OTRS can be reached. It is
possible to add, change or deactivate user accounts. Also some basic
setting for a user account can be adjusted, e.g. the language for the web
interface or the theme.
</para>

<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. To deactivate a user account set it to
"invalid" or "invalid-temporarily".
</para>
</note>

<para>
After a new user has been created the user must be added to one or more
groups or roles. You will be redirected automatically to the screen for the
group and user management when a new accounted has been created.
</para>

</sect2>

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

<para>
Every user account should at least belong to one group. The group
management can bereached via the "Groups" link.
</para>

<para>
<screenshot>
<screeninfo>Gruppenverwaltung 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
"invalid" or "invalid-temporarily".
</para>
</note>

<para>
After a default installation already four groups are available in the
system.
</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 have admin rights in the system.
          After the system has been installed only the user "root@localhost" is
          in this group.
        </entry>
      </row>
      <row>
        <entry>
          faq
        </entry>
        <entry>
          Users in this group may create and change articles in the FAQ
          system. After the system has been installed no user 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 group settings of a user the link
"Users &lt;-&gt; Groups" can be used.
</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>
A overview of all groups and users in the system is displayed in the lower
part of the screen. If you want to change the group settings of a user just
click on the username. To change the users in a group just click on the
group that you want to change.
</para>

<para>
To setup the rights for a user very graduately there are some rights that
can be set for a user account. After a default installation the follwoing
rights are 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 a ticket or entrie in queues or
          areas that belong to this groups.
        </entry>
      </row>
      <row>
        <entry>
          rw
        </entry>
        <entry>
          Full read and write access on all tickets or entries in the
          queues or areas that belong to this group.
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>
</para>

</sect2>

<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 explaine 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 manualy, 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>

<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" bzw. "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. The link "Customer Users" can be
used to mange the accounts of your customers. A customer can log in the
system via the customer interface (customer.pl). The customer interface
enables a user to manage own tickets and change the own account settings.
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 backend. More infos about customer user backends are available
in the chapter about


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

<para>
You can create new customer user accounts. All input fields that are marked
through an asterisk (*) 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 specifiy a customer ID
("Customer#"). This ID needs the system to identify the user and the
tickets of this user. Ffor example the mail address of the user can be
specified for Customer#, because a mail address is explicit.
</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:Frontend::Customer:CustomerGroupSupport">
CustomerGroupSupport
</link>

either via the graphical configuration frontend of OTRS or via inserting
this parameter into your <filename>Kernel/Config.pm</filename> file.
The parameter

<link linkend="Framework:Frontend::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 in your system. "Raw" is the default queue, all
incomming messages are 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>
The form on the right site of the screen lets you add a new queue.
You can specify the name and the group who should use the queue and if you
want the new queue to be a sub queue of another already existing queue.
</para>

<para>
If a ticket was locked by an agent, you can specify a time interval when
the ticket is unlocked automatically by the system.
</para>

<para>
If you specify a escalation time tickets which are older than this time
block newer tickets to and the escalated tickets have to be processed
first. This setting is usefull to force the processing of older tickets,
new tickets don't apear in the QueueView if a ticket is escalated.
</para>

<para>
Also you can specify that the old owner of a processed ticket is
automatically the owner again, if a followup of the old ticket is send to
the ticket system. This feature makes sure that a folowup for a ticket is
first shown to the origianl owner of the ticket who already knows the facts
of this 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>

explained more detailed this different parameters.
</para>

<para>
The different customer info parameters let you specify the queue events when
a notification to a customer is send.
</para>

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

<para>
All described config settings for new queues are also valid 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 QueueVie 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 are already two salutations available in
the system, "system standard salutation (de/buiss)" and
"system standard salutation (en)".
</para>

<para>
Because the content of a salutation can be created dynamicaly, 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 lastname 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 are already two signatures
stored in your system, "system standard signature (de/buiss)" and
"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
followup for a ticke is receifed, 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 subjectline and the text of auto answers can also be dynamicly 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
autoanswer, the first 5 lines of the customer mailtext 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 outsite 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 mal 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
incomming 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 dynamicly 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>
Since OTRS 2.0 it is possible to decode and encode SMIME messages. Also you
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>

e.g. with the

<link linkend="adminarea-sysconfig">
graphical configuration frontend
</link>

to the needs of your operating system.
</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>
Since OTRS 2.0 it is possible 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>

e.g. with the

<link linkend="adminarea-sysconfig">
graphical configuration frontend
</link>

to the needs of your operating system.
</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 userer 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", "pendig reminder" and
"removed".
</para>
</sect1>

<sect1 id="adminarea-sysconfig">
<title>The graphical configuration frontend (SysConfig)</title>

<para>
Since OTRS 2.0 it is possible to change nearly all configuration parameter
of the ticket system through the web interface. The new graphical
configuration frontend makes it possible.
</para>

<para>
<screenshot>
<screeninfo>The graphical configuration frontend 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 frontend. 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 viewd 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 mae 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 frontend is described more detailed.
</para>

</sect1>

<sect1 id="adminarea-postmasterpop3-account">
<title>Using POP3 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 POP3
accounts which can be administrated through the web interface. The
"PostMaster POP3 Account" link in the admin area of OTRS loads the
management console for the POP3 accounts.
</para>

<para>
<screenshot>
<screeninfo>POP3 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 POP3 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 PostMasterPOP3.pl or
PostMaster.pl 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 criterias that must match if
the filter rule shall be executed and of one or more actions that are
executed, if the filter criterias match. You can define filter
criterias 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 criterias 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>

<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-Ignore:
        </entry>
        <entry>
          Yes
        </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-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 nice and usefull filter rule could be to let OTRS sort mails marked for
spam with Spamassassin into the "Junk" queue automatically.
Spamassassin adds for every checked mail the "X-Spam-Flag" header.
Is the mail marked as spam, the Header is set to "Yes". So the filter criteria
is "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 aditional modules, that can be used to

<link linkend="email-receiving-filter">
filter incoming messages
</link>

more specificaly. This modules might be usefull 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 must be done
by a human person, a real agent,normaly. The GenericAgent for example can
close or move tickets, send notifications aboout 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 manualy 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>
The OTRS administrator can send a message 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>
To get an overview on the currently loged in users and their session
properties the "Session Management" link in the admin area can be used.
</para>

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

<para>
Some general information about all active sessions are displayed, e.g. how
many users currently are loged in, how many agent and customer users are
using the system, e.g. With the "kill all sessions" button all users
sessions can be deactivated. Also detailed information for every session are
available and every session can be removed separately.
</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>
A line in the log contains a timestamp, 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.
</para>
</note>

<para>
The count of the shown log entries can be specified via the

<link linkend="Framework:Core::Log:LogSystemCacheSize">
LogSystemCacheSize
</link>

config parameter.
</para>

</sect1>

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

<para>
The "Select 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>
Since OTRS 2.0 OTRS is splitted into a central framework and some
separated applications like a file manager, a web based calendar or a
web mailer. To ease the handling of the separated applications the web
based package manager can be used, the "Package Manager" link in the admin
area of OTRS opens this module.
</para>

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

<para>
The package manager can only handle opm packages, other formats (rpm, deb,
e.g.) are not supported. It is possible to define several installation
sources. Is an opm file stored on your local hard disk you can install the
package by specifying this file in the input field for "Package" via the
absolute path and the file name. The "Install" button installs this package
in your system and adds all necessary files, changes the database, e.g.
</para>

<para>
If always the most actual package should be used the packages can be
installed via a online repository too. The latest list of all applications
in the online repository can be downloaded if a server is selected via the
"Source" listbox and the "Update" button is pressed. After a while on the
right site of the screen all available application ar listed in the table
for the online repository. You can use the "Install" button in the right
column of the online repository table to integrate the module into your
system. If a package depends on other packages the package manager takes
care if the other needed applications are already installed. If a package
has been installed successfuly the application is displayed in the local
repository.
</para>

<para>
If you need to remove an application you can use the "Uninstall" button in
the local repository for the specific application. Dependencies to other
applications are also watched during deinstallation.
</para>

</sect1>

</chapter>