Torment HelpDesk over HelpDesk. What is OTRS Installing OTRS
In the articles I will try to reveal the features of implementing ITIL practices, including using OTRS.
What does the user want from the IT department in the first place?
I will try to answer, with an eye on ITIL, in the words of the user (this should be very good user) as follows: The user wants IT services to be delivered in accordance with the expectations agreed with the IT department or external service provider. If there are failures in the provision of services, then he must know where to turn and the service must be restored as quickly as possible. In addition, the user wants to receive certain IT services, such as software installation, therefore, as basic processes that can be implemented immediately, these are:
Incident management
Request Fulfillment (Service Request Management)
Examples of incidents: the PC does not turn on, an error when starting the application, etc.
Examples of service requests: installing software, granting rights to corporate resources, etc.
To prevent holivar in the comments: installing software can be both a change and a service request, and granting rights can be governed by Access Management. It all depends on the tasks facing the IT department and the description of the Services that the department provides.
Some ITIL terminology
An incident is an unplanned interruption of an IT service or a reduction in the quality of an IT service.
The goal of the Incident Management process is to restore the IT service to users as soon as possible.
A little about OTRS
There were mentions of this system on Habr, nevertheless I will remind you a little about it:
As the wiki says it is open system processing applications, although its functionality goes far beyond just processing applications.
You can download the system on the official website www.otrs.com There you can also find installation and configuration manuals.
OTRS setup
Define ticket types. More precisely, we leave those that we need to implement the above processes, since the system already has a predefined set of settings.
You can optionally define queues, such as Hardware, Printing, Software. Each queue has the ability to configure agent access. Agents are employees who do the work of resolving incidents, usually ServiceDesk employees.
Queues must have calendars defined, i.e. the availability time of agents responsible for a particular queue, in accordance with their work schedule.
Calendar settings are made in the module:
Core::Time::Calendar1
Up to 10 such calendars can be assigned, and for each you can specify agents' working hours for each day of the week, annual and one-time holidays and days off. The time in accordance with the SLA will take into account the availability of agents.
Define Services (i.e. Service Catalog) and SLA.
At least one SLA is sufficient, in which the first reaction time and the decision time will be determined.
Applications are received via WEB-Interface, by phone, through the interface of IT department agents.
Despite the fact that OTRS has user interface to work with requests, we implemented interaction through an internal site that runs on joomla, which has the OTRS Gateway plugin (in the house that Jack built). The plugin allows you to create applications, and view "your", previously created requests.
The incoming request receives the state new. In the agent interface, the time before the first reaction and before the decision is available.
The fact of the start of work with the application is fixed by the answer created on the basis of the template
After that, the request is blocked and it receives the open state. At the same time, a message is sent to the user stating that the application has been submitted for consideration. The counter of time until the first reaction is reset.
The request must be described, if necessary, incorrectly entered data by the user is corrected.
After the decision, we transfer the request to the pending auto close+ state.
The waiting time is set by the parameter:
$Self->("Ticket::Frontend::PendingDiffTime") = "14400"
If no additions to the request are received from the user, it will be transferred to the closed successfull state. Yes, it may not be entirely fair, but on the other hand, you will not ask the user to force him to additionally enter the WEB-Interface and write comments on the completed request.
$Self->(Ticket::StateAfterPending) = (
"pending auto close+" => "closed successful",
"pending auto close-" => "closed unsuccessful"
The Unix cron scheduler is responsible for the state translation, in which it is necessary to set the status update frequency to less than, default 2 hours:
check every 120 min the pending jobs
45 */2 * * * $HOME/bin/PendingJobs.pl >> /dev/null
We change the parameter, in our case, setting the time equal to 5 minutes. At the same time, we keep in mind the performance of the system.
check every 5 min the pending jobs
*/5 * * * * $HOME/bin/PendingJobs.pl >> /dev/null
For convenient display of requests in the agent interface, set the parameter:
Core::Ticket::ViewableStateType,
leaving only the new and open states, thus hiding the wait states in the agent interface.
Challenges
We partially shift the description of the request onto the shoulders of the user, without inflating the description dialog so as not to tire the user. Specify Service and Type as required fields. Incorrectly described requests are corrected by ServiceDesk.
It is necessary to record all user requests, we solve this problem through the motivation of Service Desk employees.
Reporting
Reporting is generated using standard functionality using the Report Creation Wizard, for example:
Average response time by performer
Average response time by service
Average decision time by performers
Average decision time for services
Number of requests for the reporting period (month) by performers
Number of requests for the reporting period (month) for services
The percentage of requests completed in accordance with the SLA to the total number of requests.
Reporting on performers is necessary to assess (motivate) the specialists involved in the Operation of the Services.
Reporting on the Services is provided to interested parties.
In addition, reports obtained by SQL queries to the database and they are the main indicator of the work of the IT service:
The percentage of requests completed according to the SLA. (in our case it is 80%, we strive for 90%)
Apparently, an error in the localization file. We find the file c:\otrs\Kernel\Language\ru.pm, look for the text “Logout” in it and change %c %c to %s %s.
Restart the Apache service - got better.
Setting up queues.
In Queue Management, select Postmaster. Change the name of the queue to System support, click Submit.
Mail setup.
Set up the ability to receive applications by e-mail.
To be able to register applications by e-mail, you need to know the login and password of the account on Mailbox which these applications will come. In the settings of this mailbox, you need to specify "Delete letters from the server when letters are downloaded using IMAP (POP)".
By default, the system picks up mail every ten minutes.
Go to Administration - Mail Setup - Mail Accounts for PostMaster. The IMAP service must be running.
Specify the type, mail server. Select Redirect to the selected queue, where the queue is System support. Click Send.
Go to Administration - Mail Settings - Email Addresses.
In the System address management section Email select the address otrs@localhost. We change it to the address to which new applications will come. Change the display name to "System Support Services", specify the desired queue. Click Send.
Let's configure the ability to send messages from the same email address to which new requests will come.
In this guide, MS Exchange 2008 is used as a mail server. Go to Administration - System Administration - System Configuration. Select Framework, then Core::Sendmail. Customize:
SendmailModule - select SMTPTLS;
SendmailModule::Host – specify the outgoing mail server;
SendmailModule::Port - specify the port;
SendmailModule:AuthUser - specify the account login;
SendmailModule::AuthPassword - specify the account password;
SendmailNotificationEnvelopeFrom - specify the system email address.
Setting up the working calendar of the customer support service.
Go to Administration - System Administration - System Configuration - Framework - Core::Time.
Select general working hours. IN this example support is provided from 8.00 to 17.00.
Click the Update button.
We return to the system configuration - Framework-Core::Time::Calendar1.
We can change the name of the calendar.
Set up working hours, holidays.
Let's add groups to differentiate access rights.
Administration - Agent Management - Groups.
In the Manage Groups section, select Add Group. Specify the name of the group - System Support. Click the Send button.
Next, we associate this group with support service agents by checking the necessary checkboxes.
We add another group for regular support agents, who will have limited rights in OTRS.
Set the required checkboxes. Click Send.
By analogy, we create other groups that we need.
Here we will add agents that will have rights to administer OTRS to the admin group.
Setting up queues
Let's set up responses, with the help of which specialists will be able to respond to user requests in the system.
Administration - Queue settings - Templates.
In the Template Management section, delete the test answer.
Now select the empty answer template and edit it. Change the name of the response to New response. Leave the body of the letter blank. Click Send.
Let's set up a greeting that will be displayed in the body of the letter when the specialist answers.
Go to Administration - Queue Settings - Greetings. Select system standard salutation (en) and change it. Click Send.
Let's set up a signature that will be displayed at the end of the letter when a specialist answers.
Administration - Setting up queues - Signatures. Select system standard signature (en) and change it.
Now let's set up the actual queues themselves.
Administration - Setting up queues - Queues.
Select the System Support queue. We indicate the name, group, address of the system, Parameters of repeated answers - perhaps we indicate our calendar.
By analogy, we set up the rest of the queues.
Setting up an auto-response that will come to the user when registering a new application.
Administration - Queue settings - Auto-replies.
In the Manage auto-replies section, select default reply (after new ticket has been created) and change it. Click Send.
Name: Create a new ticket
Subject: RE:
Body of the letter:
Hello,
Your application
Application text:
———————————————
Bind auto-replies to queues.
Administration - Setting up queues - Auto-replies-Queue.
In the Communication Queues with Auto-responses section, select the System support queue, in the auto-response section, select Create a new ticket. Click Send.
By analogy, we add auto-responses for all queues.
Set up account agent
Administration - Agents - Agent Management.
Choosing an agent. Make sure the email field is filled in.
We turn on all notifications so that the specialist can quickly respond to new events.
In the Review update time item, select 2 minutes. In the comment field, you can specify the phone number of a support specialist.
In the My queues field, select (highlight) the desired queue (or several).
Click Send.
Set up notifications for specialists
Administration - Setting up requests - Notifying agents.
In the Manage Notifications section, change the default text to your own for each notification.
en::Agent::AddNote– this notification will come in case of adding a new note to the application.
Subject: New note! (
Body of the letter:
Hello,
The note:
—————————————
Helpdesk Notification Service
en::Agent::Escalation– notification of the escalation of the application (the time allotted for solving the application has expired)
Subject: Ticket escalated! (
Body of the letter:
———————————————————————————————-
Hello,
Application number [
Escalated V:
Escalated With:
Posted by(A):
Pay attention:
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::EscalationNotifyBefore– notification of an imminent escalation of the application (the allotted time for the execution of the application ends)
Subject: Notification of an imminent escalation of the application! (
Body of the letter:
———————————————————————————————-
Hello,
Hare number [
Escalated V:
Escalated With:
Posted by(A):
Pay attention:
—————————————-
Helpdesk Notification Service
———————————————————————————————-
en::Agent::FollowUp– notification that the user does not agree with the decision on the application and returned it to work
Subject: Application close denied! The application has been returned to work! (
Body of the letter:
———————————————————————————————-
Hello,
Closing application number
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::LockTimeout– notification that the application blocking period has expired
Subject: Application blocking period expired! (
Body of the letter:
———————————————————————————————-
Hello,
Application blocking period number [
Application has been unlocked.
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::Move– notification that the specialist sent the application to another queue
Subject: Application queued
Body of the letter:
———————————————————————————————-
Hello,
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::NewTicket – notification that a new ticket has appeared in the queue
Subject: New request in line! (
Body of the letter:
———————————————————————————————-
Hello,
H new application V queues
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::OwnerUpdate– notification that a specialist has been appointed by the owner of the application
Subject: You have been designated as the ticket owner! (
Body of the letter:
———————————————————————————————-
Hello,
Application number [
A comment:
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::PendingReminder – notification that a ticket reminder is configured
Subject: Application Reminder! (
Body of the letter:
———————————————————————————————-
Hello,
Application [
Wrote:
Note:
—————————————
Helpdesk Notification Service
———————————————————————————————-
en::Agent::ResponsibleUpdate– notification that the specialist has been appointed responsible for the application
Subject: You have been placed in charge of an application! (
Body of the letter:
———————————————————————————————-
Hello,
You appointed responsible on application number [
A comment:
—————————————-
Helpdesk Notification Service
———————————————————————————————-
en::Agent::ServiceUpdate- notification that the service has been updated
Subject: Service changed to
Body of the letter:
———————————————————————————————-
Hello,
—————————————-
Helpdesk Notification Service
———————————————————————————————-
Set up notifications for users
Administration - Setting up requests - Event notification.
Click the Add Notification button.
Specify the name of the event.
Specify the event upon completion of which the user will receive a notification.
Specify who will receive the event notification.
Sample message text:
——————————————————————————————
Hello,
Responsible for your application number
Telephone:
Service:
Service:
Decision Deadline:
———————————————
User Support
—————————————————————————————-
Similarly, we create a notification for closing the application.
Click the Add notification button, specify the name - The application is closed.
Sample message text:
——————————————————————————————
Application number
Solution:
Application subject:
Responsible:
Telephone:
If you do not agree with the decision and want to return the application to work, please reply to this letter and write about the problems encountered during the solution.
If you agree with the decision, please do not reply to this email!
———————————————
User Support
——————————————————————————————
Go to Administration - System Administration - System Configuration - Tickey - Core::Ticket.
In the Ticket::Hook parameter, change the value to Ticket No.
The value of the Ticket::Service (for SLA support) and Ticket::Service::Default::UnknownCustomer parameters is set to Yes.
The Ticket::NumberGenerator parameter is set to Autoincrement - to know how many tickets have passed through the system.
Click Update.
Set up services.
You need to add an SLA to this service.
Go to Administration - Ticket Settings - Service Level Agreement - Add SLA.
Add an SLA to install a new one software. We set a name for the SLA, select the service to which the SLA belongs, select our calendar, set 7200 minutes to complete the request; escalation will occur after 60% of the allotted time. Click Send.
Job setup.
Go to Administration - System Administration - Task Scheduler - Add Task.
Let's add a task that will automatically block unlocked requests. Applications will be assigned to a specialist in case the user has returned the application to work.
Job name - Lock open tickets
Automatic execution - in the column Run in minutes, select every 10 minutes, in the columns Run in hours and Run in days, select all values.
Select requests –Status – Open. Request blocking – Unblocked.
Update/Add Order Attributes - Set New Block State - Block.
Click Send.
Let's add a job for the System Support queue that will automatically move tickets assigned to a System Support Specialist to the System Support queue.
Automatic execution - in the column Run in minutes, select every 20 minutes, in the columns Run in hours and Run in days, select all values.
Select applications - Agent / Owner - select technical support specialists.
Update/Add Ticket Attributes - Set New Queue - System Support.
Click Send.
Let's continue to configure the system.
Administration - System Administration - System Configuration - Framework - Core.
Set SecureMode to Yes.
Click Update.
Check the values of the FQDN, AdminEmail, Organization, NotificationSenderEmail, NotificationSenderName parameters.
Go to Framework - Frontend::Customer
CustomerHeadline - specify the name of the support service
CustomerPanelLostPassword - No (we will disable the password recovery function, since we have pass-through authorization)
CustomerPanelCreateAccount - No (our data is taken from the active tree)
Click Send.
Set up the ability for specialists to monitor applications.
Specialists will be able to receive notifications about changes in the applications of colleagues.
System Configuration - Ticket - Core::TicketWatcher
Ticket::Watcher - Yes
Set up the unit of measure for working time.
System Configuration - Ticket - Frontend::Agent
Ticket::Frontend::TimeUnits - (minutes)
Click Update.
Set up notifications
System Configuration - Ticket - Frontend::Agent::ModuleNotify
Turn on the checkbox next to Frontend::NotifyModule###5-Ticket::TicketEscalation.
Customizing the interface for comfortable work with applications
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::ModuleRegistration
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewClose
Ticket::Frontend::AgentTicketClose###Service - Yes
Administration - System Administration - System Configuration - Ticket -Frontend::Agent::Ticket::ViewForward
Ticket::Frontend::AgentTicketForward###RequiredLock - No
Ticket::Frontend::AgentTicketForward###StateDefault-open
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewMerge
Ticket::Frontend::AgentTicketMerge###RequiredLock - No
Ticket::Frontend::MergeText - "Ticket" » merged with application «
Ticket::Frontend::AutomaticMergeSubject - Tickets merged
Ticket::Frontend::AutomaticMergeText - "Ticket" » merged with application « ».»
Click Update.
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewOwner
Ticket::Frontend::AgentTicketOwner###Service - Yes
Ticket::Frontend::AgentTicketOwner###Queue - Yes
Ticket::Frontend::AgentTicketOwner###Note - No
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewPending
Ticket::Frontend::AgentTicketPending###RequiredLock - No
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewPriority
Ticket::Frontend::AgentTicketPriority###RequiredLock - No
Ticket::Frontend::AgentTicketPriority###Note - No
Let's add additional buttons in the agent's interface to the upper left corner
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::ToolBarModule
Set the checkboxes opposite:
Frontend::ToolBarModule###1-Ticket::AgentTicketQueue
Frontend::ToolBarModule###2-Ticket::AgentTicketStatus
Frontend::ToolBarModule###3-Ticket::AgentTicketEscalation
Frontend::ToolBarModule###4-Ticket::AgentTicketPhone
Remove unnecessary items from the user's personal account
Administration - System Administration - System Configuration - Ticket - Frontend::Customer::TicketViewNew
Ticket::Frontend::CustomerTicketMessage###QueueDefault - System support
Ticket::Frontend::CustomerTicketMessage###Service - No
Ticket::Frontend::CustomerTicketMessage###SLA - No (this item will become available when there is enough ticket database to complete the SLA)
We will make it so that the user in his personal account can see who is the owner of his application
Administration - System Administration - System Configuration - Ticket - Frontend::Customer::TicketOverView
Ticket::Frontend::CustomerTicketOverview###Owner - Yes
This completes the basic OTRS setup.
More recently, a bright idea has appeared to systematize the work of our HelpDesk service, or as ServiceDesk is now called, as much as possible using a system for automated collection and processing of applications (bearing the same name).
So let's get started.
1. Let's start by analyzing the most suitable systems for such a service
- Having studied the comparison table of PAID HelpDesk systems and FREE, at first glance of the most specialized site about HelpDesk, I realized that the data seemed to be terribly outdated and did not contain the full picture.
- Turning to the search, I came across a comparison on the ru-board. Here everything was already much more detailed and not biased. But relevance also suffered, the header was updated for the last time in early 2008. Another attempt to build a similar branch also died without waiting for its apogee, but having managed to collect quite a lot of information, albeit without links.
- Another great resource is http://netdocs.ru/, but I couldn't go through it completely.
- There are also topics on the nowa.cc forum, but there, as always, everything is closed to the "passing by", and there is not much information.
- I haven't been able to find anything else.
2. Armed with these four comparisons, I began to analyze which systems fit my requirements the most. List in descending order of importance of characteristics: - Ability to test the system before purchase
- WEB muzzle of the applicant
- WEB muzzle specialist
- E-mail notification of the applicant and specialist
- Ability to change the interface
- Start-up time for test operation
- Russification
- Accounting for the material base
- Importing Users from Global Directory Services
- License
3. Armed with ten criteria, I was puzzled at the first one. He turned out to be decisive.
Of the seemingly satisfying systems taken for the test: - (Free, license GNU ) - http://otrs.org
- PerlDesk v2.25(Paid) http://www.perldesk.com/
- Claris(Paid) - http://saas.claris.su/
- Itilium(Paid) - http://www.itilium.ru/
- (Paid) - http://www.adventnet.com
- HP OpenView (Paid) - ru-board
- Kayako(Paid) - http://www.kayako.com/
- IPI.HELPDESK
(Paid) - http://ipi-helpdesk.ru/
4. It was possible to install only half of the tests:
- OTRS - Open Ticket Request System (Free, license GNU ) - http://otrs.org
- Itilium(Paid) - http://www.itilium.ru/
- ManageEngine ServiceDesk Plus(Paid) - http://www.adventnet.com
- HP OpenView (Paid) - ru-board
Due to the lack of trial or pills...
- The HP OpenView (Windows) I was able to find version 4.5 was very outdated and unsupported. HP pushed off version 5.1 and created another giant version 7.5, after installing which I realized that this is mostly a server monitoring system and for organizing my service HelpDesk does not fit at all.
- Itilium (Windows), based on the 1C platform, was found, installed, having suffered for several days with the search for the desired version, suitable for the version of the installed 1C platform. In the end, I had S-ka 8.0, 8.1, 8.2 installed and Itilium version 8.3.1 was installed on 1C 8.2, screwed to 1C special WEB extension, version 8.0.11.1. By the way, the next version of Itilium is already becoming unknown, because the WEB extension in 1C 8.3 will be redesigned and integrated into 1C.
- OTRS(Windows, Linux), oddly enough, was not easy to install. Because I installed it third, then the ports that WEB usually goes through were already occupied and the installation from the installation package failed. It's strange, but in the installation configurator of such a serious system there is no "Advanced" installation option. Installed by default and crashes with an error. But there is an option to install separate packages. It suited me, but finding these packages was not so easy! Because version 2.4.7 is almost no longer supported due to the expectation in mid-August 2010 of a new version 3.0. For some reason, these packages also disappeared from the official site (it seems that they decided to save 50 megabytes on hosting). I had a hard time getting the necessary versions: 1. distribution kit of the required version Perl 5.6.1.633, with difficulty but found - http://crymchaks.at.ua/files/ActivePerl-5.6.1.633-MSWin32-x86.msi.7z. 2. Link to Apache 1.3.27- http://www.filewatcher.com/m/apache_1.3.27-win32-x86-no_src.msi.2192896.0.0.html . 3. And here is the packageOTRS-Win32-Perl-Packages have not been able to find it. (Not working link- ftp://ftp.otrs.org/pub/otrs/misc/win32/OTRS-Win32-Perl-Packages.zip , if anyone finds it - please share, there's already a queue!) I had to install it on another server from the installation package. No problem.
- ManageEngine ServiceDesk Plus (Windows) - Installed version 7.6.0 last. And thank God, I got it the first time without any tambourines, though I asked for a pill on the ru-board.
5. It took me two weeks to test these systems. I will not build graphs and tables with scores. I will say in short:
- Itilium - I have not been able to receive a single notification by mail about the creation or updating of a ticket (ticket application). In 1C, they formed such long branches of directories and so many required fields to fill in that in order to create the first application, I had to fill in the bare minimum for several days. But there just wasn’t enough time to fill everything and deal with all the possibilities, all the more so to read 2 manuals for installing and using the system in the amount of 250 and 90 pages ... I concluded that in order to implement this system, you need not only to PAY FOR MANUALS, but also for implementation by their specialists, not to mention the fact that you will also have to pay for the system itself.
- OTRS- We managed to form the first application in the 10th minute of work in the system, but there is still no way to receive a mail notification. :(In general, this is the fastest of the tested systems. True, it took a long time to translate everything, everything, all the rules, the names of incidents, because apart from the menu and the admin interface. Very few menu descriptions in the administration, I had tofor a long timeto puzzle over to understand what groups serve and what is connected with what, although just a couple of phrases would suffice. Except for the fact that I didn’t get the mail, thenThe Open Ticket Request System is a pretty good, uncomplicated system that suits a lot of people. But in order to expand it, you need to delve into not only PHP, but also the business rules that organize the operation of this system, and any similar one.
- ManageEngine ServiceDesk Plus - It took about a day to launch the first application, but then it went like clockwork. Almost everything is well described, and it works with minimal filling in directories. In templates, you can change not only the text, but also the location of the windows, and indeed their presence, with just one click of the mouse, as they say Drag&Drop. I settled on this system, as I quickly set notifications about tickets to mail, and maybe also to SMS. Wonderful work with the material base (inventory of IT system equipment), with reference to the user, which in turn are imported from Active Directory or LDAP. Also, standard authorization can be supplemented without much difficulty with domain authorization and leave the user the ability to choose a login method.
In general, some positive emotions from working with ManageEngine ServiceDesk Plus 7.0, which is what I wish you.
The only thing is that there is no good unofficial site for more than one system :(
If anything, write to the topic on ru-board, we will share our experience of using it.
I hope this article will help you save some of that precious time, which is better spent studying the history of the endangered Crimean people of the Krymchak ethnic group.
Good luck to all!PS (after 2 years): At the moment I'm using OTRS 3.1.3 for receiving, processing tickets (ticket) and happy with my choice.
Pros:
- works fast (Linux)
- highly customizable reports
- about 1300 advanced system configuration sections with full-text search on them
- no problem updating a running system
- hot buttons
Minuses: - due to such an abundance of advanced settings sections, it is sometimes very difficult to find the right one
- I could not set it up so that when answering a request, the default status would be "closed successfully"
- could not reduce the size of the text field for entering the content of the application when responding to the application (the "Reply" button does not fit in the newly opened window).
I will also add a recently appeared review of paid and free bug tracking systems, most of which are HelpDesk or ServiceDesk systems. So what is OTRS?
As the name "Open source Ticket Request System" implies, OTRS is a system for accounting (receiving and processing) applications (tickets). Under the application (ticket) I understand the appeal of someone to someone. Thus, the possibilities of using OTRS are much wider than Helpdesk in the IT department. For example, the ideology of the system perfectly fits the work of the support department for anything, the work of the sales department to receive requests for issuing a commercial offer or invoice, the work of the quality control service, etc. But for now, I would like to limit myself to the IT department, whose Helpdesk service I would like to automate, so the following description will describe solutions specifically for Helpdesk.
What tasks is designed to solve OTRS for Helpdesk:
- Registration of appeals. IT staff need to know what the call was; users need to understand that the appeal has reached the address and is not lost. In addition, it is convenient for the user that any requests can be processed in the same unified way.
- Accounting and processing of appeals. IT staff must know what calls are available at any given moment and take action to fulfill them; users need to understand what is going on with their message.
- Automation of order fulfillment. There is a thesis that any problem can be solved by a competent specialist within 1 hour. It is only necessary that the problem immediately fall into the hands of such a specialist. Therefore, if you automate the processing of incoming requests, you can drastically shorten the path to contacting the appropriate specialist.
- Fight against "Secret Knowledge". Information on applications and actions on applications should be recorded so that it is known NOT only to the employee who undertook its implementation. Otherwise, the execution of applications may stumble over the human factor, and the application will not be executed because they simply do not know about it, although there are more than enough people who could fulfill it.
The ideology of the system implies that any appeal must be recorded. Appeals are recorded in the form of an application. In order to avoid misunderstandings, I would like to introduce some basic concepts:
- The client is the one who forms the application. This is an external user of the system.
- Agent - the one who processes the application. This is an internal user of the system.
Fixing a request is the identification of the Client, assigning a unique number to the application and pre-processing in order to categorize the request and notify the Agent (s) about a new application.
Applications are placed in queues.
- Queue - the location of the request.
Queues allow:
- Divide the total array of applications.
- Provide different access for Agents to applications.
- Notify certain Agents about events with an application.
- Set up various automatic responses to Clients depending on the parameters of the request
How do applications appear in the system? 3 ways are offered:
- Email message. OTRS checks the mailbox(es) and turns each message into a ticket
- Filling out the form by the Client through the web interface
- Creation of an application by the Agent on the basis of a personal request, for example, by phone or in words in a smoking room.
Let's break this for now. The next article will be devoted to a brief description of the installation experience and a more detailed description of the initial system setup.
(O pen source T icket R request S ystem is an open ticketing system that provides a single point of contact for users, IT staff, IT services, and any external organization. The program is written in Perl. OTRS supports many databases (MySQL, PostgreSQL, etc.) and integration with LDAP directories.
This guide will help you install and configure OTRS on a CentOS 7 server.
Requirements
- CentOS 7 server;
- Non-root user with sudo access (read about user privileges here);
- 4 GB of swap space (more on setting up swap in this guide).
Step 1 Install MariaDB
First you need to install all OTRS dependencies.
To do this, you need the EPEL (Extra Packages for Enterprise Linux) repository. Add it:
sudo yum install epel-release
Update system:
Install MariaDB (a fork of MySQL):
sudo yum install mariadb-server mariadb
For OTRS to work correctly, you need to change the default MySQL settings. Open the configuration file in the vi editor:
sudo vi /etc/my.cnf
Add the following lines to the section, which define the sizes of some files:
max_allowed_packet = 20M
query_cache_size = 32M
innodb_log_file_size = 256M
datadir=/var/lib/mysql
. . .
Save and close the file.
Note Note: These changes must be made before starting MySQL.
Start MariaDB:
sudo systemctl start mariadb.service
Run a MySQL script that will remove all unsafe options.
sudo mysql_secure_installation
The script will ask a few questions. To accept the default values, simply press Enter. Be sure to change only the standard root password. Choose a strong password.
Step 2: Installing OTRS
You can install OTRS using a precompiled RPM package. Download this package from the official program repository.
Note A: Before downloading a package, make sure it is the latest version.
wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-5.0.7-01.noarch.rpm
Install OTRS:
sudo yum install otrs-5.0.7-01.noarch.rpm
The OTRS program is written in Perl, so some Perl modules are required to run it. To determine the missing modules, use the CheckModules.pl script (it comes with the OTRS package):
sudo /opt/otrs/bin/otrs.CheckModules.pl
The output looks something like this:
o Apache::DBI......................ok (v1.12)
o Apache2::Reload.............FAILED! Not all prerequisites for this module correctly installed.
. . .
o XML::LibXSLT......................ok (v1.80)
o XML::Parser......................ok (v2.41)
o YAML::XS......................Not installed! Use: "yum install "perl(YAML::XS)"" (required - Very important)
Some modules are needed only for additional functions (for example, to communicate with other databases or to process mail with Chinese characters). To install the missing modules, use the yum commands suggested in the output.
sudo yum install "perl(Apache2::Reload)" "perl(Crypt::Eksblowfish::Bcrypt)" "perl(Encode::HanExtra)" "perl(JSON::XS)" "perl(Mail::IMAPClient) " "perl(ModPerl::Util)" "perl(Text::CSV_XS)" "perl(YAML::XS)"
After installing all the necessary modules, run the script again to make sure that all requirements are met.
Step 3: Setting up OTRS
Now you need to configure the database and OTRS mail. First restart Apache to update the settings with the OTRS settings.
sudo systemctl restart httpd.service
Now open the installer web page:
http://your_server_ip/otrs/installer.pl
The welcome page will appear on the screen. Click Next. After that, you need to accept the license; read it and click Accept license and continue.
On the next page, you need to select a database. Select MySQL from the dropdown menu and click Create a new database for OTRS (typically MySQL is selected by default). Click Next.
After that, you need to specify the previously created MySQL database credentials. To make sure the data is correct, click Check database settings.
The installer will generate credentials for the new database. You don't need to remember this generated password as you won't need it later, so just click Next to continue. After that, the installer will create a new database. Click Next.
After that, you need to specify the system parameters:
- FQDN: The domain name or IP address of the server.
- Admin Email: System administrator's email address. This is where the program will send error notifications.
- Organization: The name of the organization.
The rest of the default settings can be left unchanged.
To be able to receive emails from users, you need to set up incoming mail.
Locate the Configure Inbound Mail section and provide the required credentials. For example, if you use the Google mail provider, you can create an app password and enter the following details:
- Inbound mail type: IMAPS
- Inbound mail host: imap.gmail.com
- Inbound mail user: your_email_address
- Inbound mail password: your_app_password
To check the configuration, click the corresponding button. Within a few seconds, the following message will appear:
Mail check successful
Press OK to go to the last screen.
OTRS installation and configuration is complete!. A link to access the admin toolbar and superuser credentials will appear on the screen.
Important! Don't forget to write down the generated password for the root@localhost user and the URL of the start page.
Now it remains only to start the OTRS daemon and enable its cronjob:
sudo su -otrs -c "/opt/otrs/bin/otrs.Daemon.pl start"
sudo su -otrs -c "/opt/otrs/bin/Cron.sh start"
4: OTRS Protection
At this point, you have a fully functional application. However, using a superuser account with OTRS is not safe. Therefore, it is necessary to create a new agent.
In OTRS, agents are users who have access to system functions. In this example, we will create one agent that will have access to all OTRS features.
To create a new agent, log in as root@localhost. Open the link you received at the end of the installation and enter the username root@localhost and password (see end of section 3).
The main panel will appear on the screen. It contains several widgets that show various ticket information, statistics, news, etc. You can freely position them by drag and drop or disable them in the settings.
First you need to create a new agent. At the top of the control panel there will be a warning highlighted in red:
Don't use the Superuser account to work with OTRS! Create new Agents and work with these accounts instead. →
To create a new agent, click on this message and then click Add agent. A number of fields will appear on the screen. Fortunately, filling out all of these fields is optional - most of the default options work. You only need to fill in the fields First Name, Last Name, Username, Password and Email.
After that, you need to change the group relations of the new agent. The new agent will also be an administrator, so he needs read and write permissions in all groups. To do this, check the box next to RW in the Change Group Relations for Agent settings.
Click Submit. Now you can log out of the superuser account and use the new agent to run. By clicking on the gear icon in the upper left corner of the screen, you can change the agent's settings (change the password, select the interface language, configure notifications, queues, interface theme, and much more).
Step 5: Manage Tickets
Now let's look at ticket management. Customers can submit tickets to OTRS in two ways: using the interface or via email.
http://your_server_ip/otrs/customer.pl
Here you can create a user account and submit a ticket.
You can also create a new ticket by sending an email to the email address provided during setup. By default, all tickets received by mail are stored in the same queue and have normal priority. All customer tickets can be viewed in the customer web interface, regardless of how they were submitted.
All new tickets created using the interface will immediately appear on the agent's dashboard. Tickets sent by mail may not immediately appear on the dashboard because OTRS checks for new tickets every 10 minutes.
On the agent's dashboard, you can find information about all current tickets: their status (new, open, escalation, etc.), their "age" (time elapsed since the ticket was received), and subject.
To view ticket details, you can click on its number in the Ticket # column. In this window, the agent can also interact with the ticket (change its priority or state, move it to another queue, close it, and so on).
Note: Learn more about the OTRS program in the official guide.
Tags: ,
Ticket::Frontend::AutomaticMergeSubject - Tickets merged
Ticket::Frontend::AutomaticMergeText - "Ticket" » merged with application « ».»
Click Update.
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewOwner
Ticket::Frontend::AgentTicketOwner###Service - Yes
Ticket::Frontend::AgentTicketOwner###Queue - Yes
Ticket::Frontend::AgentTicketOwner###Note - No
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewPending
Ticket::Frontend::AgentTicketPending###RequiredLock - No
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::Ticket::ViewPriority
Ticket::Frontend::AgentTicketPriority###RequiredLock - No
Ticket::Frontend::AgentTicketPriority###Note - No
Let's add additional buttons in the agent's interface to the upper left corner
Administration - System Administration - System Configuration - Ticket - Frontend::Agent::ToolBarModule
Set the checkboxes opposite:
Frontend::ToolBarModule###1-Ticket::AgentTicketQueue
Frontend::ToolBarModule###2-Ticket::AgentTicketStatus
Frontend::ToolBarModule###3-Ticket::AgentTicketEscalation
Frontend::ToolBarModule###4-Ticket::AgentTicketPhone
Remove unnecessary items from the user's personal account
Administration - System Administration - System Configuration - Ticket - Frontend::Customer::TicketViewNew
Ticket::Frontend::CustomerTicketMessage###QueueDefault - System support
Ticket::Frontend::CustomerTicketMessage###Service - No
Ticket::Frontend::CustomerTicketMessage###SLA - No (this item will become available when there is enough ticket database to complete the SLA)
We will make it so that the user in his personal account can see who is the owner of his application
Administration - System Administration - System Configuration - Ticket - Frontend::Customer::TicketOverView
Ticket::Frontend::CustomerTicketOverview###Owner - Yes
This completes the basic OTRS setup.
More recently, a bright idea has appeared to systematize the work of our HelpDesk service, or as ServiceDesk is now called, as much as possible using a system for automated collection and processing of applications (bearing the same name).
So let's get started.
1. Let's start by analyzing the most suitable systems for such a service
- Having studied the comparison table of PAID HelpDesk systems and FREE, at first glance of the most specialized site about HelpDesk, I realized that the data seemed to be terribly outdated and did not contain the full picture.
- Turning to the search, I came across a comparison on the ru-board. Here everything was already much more detailed and not biased. But relevance also suffered, the header was updated for the last time in early 2008. Another attempt to build a similar branch also died without waiting for its apogee, but having managed to collect quite a lot of information, albeit without links.
- Another great resource is http://netdocs.ru/, but I couldn't go through it completely.
- There are also topics on the nowa.cc forum, but there, as always, everything is closed to the "passing by", and there is not much information.
- I haven't been able to find anything else.
- Ability to test the system before purchase
- WEB muzzle of the applicant
- WEB muzzle specialist
- E-mail notification of the applicant and specialist
- Ability to change the interface
- Start-up time for test operation
- Russification
- Accounting for the material base
- Importing Users from Global Directory Services
- License
Of the seemingly satisfying systems taken for the test:
- (Free, license GNU ) - http://otrs.org
- PerlDesk v2.25(Paid) http://www.perldesk.com/
- Claris(Paid) - http://saas.claris.su/
- Itilium(Paid) - http://www.itilium.ru/
- (Paid) - http://www.adventnet.com
- HP OpenView (Paid) - ru-board
- Kayako(Paid) - http://www.kayako.com/
- IPI.HELPDESK (Paid) - http://ipi-helpdesk.ru/
- OTRS - Open Ticket Request System (Free, license GNU ) - http://otrs.org
- Itilium(Paid) - http://www.itilium.ru/
- ManageEngine ServiceDesk Plus(Paid) - http://www.adventnet.com
- HP OpenView (Paid) - ru-board
- The HP OpenView (Windows) I was able to find version 4.5 was very outdated and unsupported. HP pushed off version 5.1 and created another giant version 7.5, after installing which I realized that this is mostly a server monitoring system and for organizing my service HelpDesk does not fit at all.
- Itilium (Windows), based on the 1C platform, was found, installed, having suffered for several days with the search for the desired version, suitable for the version of the installed 1C platform. In the end, I had S-ka 8.0, 8.1, 8.2 installed and Itilium version 8.3.1 was installed on 1C 8.2, screwed to 1C special WEB extension, version 8.0.11.1. By the way, the next version of Itilium is already becoming unknown, because the WEB extension in 1C 8.3 will be redesigned and integrated into 1C.
- OTRS(Windows, Linux), oddly enough, was not easy to install. Because I installed it third, then the ports that WEB usually goes through were already occupied and the installation from the installation package failed. It's strange, but in the installation configurator of such a serious system there is no "Advanced" installation option. Installed by default and crashes with an error. But there is an option to install separate packages. It suited me, but finding these packages was not so easy! Because version 2.4.7 is almost no longer supported due to the expectation in mid-August 2010 of a new version 3.0. For some reason, these packages also disappeared from the official site (it seems that they decided to save 50 megabytes on hosting). I had a hard time getting the necessary versions: 1. distribution kit of the required version Perl 5.6.1.633, with difficulty but found - http://crymchaks.at.ua/files/ActivePerl-5.6.1.633-MSWin32-x86.msi.7z. 2. Link to Apache 1.3.27- http://www.filewatcher.com/m/apache_1.3.27-win32-x86-no_src.msi.2192896.0.0.html . 3. And here is the packageOTRS-Win32-Perl-Packages have not been able to find it. (Not working link- ftp://ftp.otrs.org/pub/otrs/misc/win32/OTRS-Win32-Perl-Packages.zip , if anyone finds it - please share, there's already a queue!) I had to install it on another server from the installation package. No problem.
- ManageEngine ServiceDesk Plus (Windows) - Installed version 7.6.0 last. And thank God, I got it the first time without any tambourines, though I asked for a pill on the ru-board.
- Itilium - I have not been able to receive a single notification by mail about the creation or updating of a ticket (ticket application). In 1C, they formed such long branches of directories and so many required fields to fill in that in order to create the first application, I had to fill in the bare minimum for several days. But there just wasn’t enough time to fill everything and deal with all the possibilities, all the more so to read 2 manuals for installing and using the system in the amount of 250 and 90 pages ... I concluded that in order to implement this system, you need not only to PAY FOR MANUALS, but also for implementation by their specialists, not to mention the fact that you will also have to pay for the system itself.
- OTRS- We managed to form the first application in the 10th minute of work in the system, but there is still no way to receive a mail notification. :(In general, this is the fastest of the tested systems. True, it took a long time to translate everything, everything, all the rules, the names of incidents, because apart from the menu and the admin interface. Very few menu descriptions in the administration, I had tofor a long timeto puzzle over to understand what groups serve and what is connected with what, although just a couple of phrases would suffice. Except for the fact that I didn’t get the mail, thenThe Open Ticket Request System is a pretty good, uncomplicated system that suits a lot of people. But in order to expand it, you need to delve into not only PHP, but also the business rules that organize the operation of this system, and any similar one.
- ManageEngine ServiceDesk Plus - It took about a day to launch the first application, but then it went like clockwork. Almost everything is well described, and it works with minimal filling in directories. In templates, you can change not only the text, but also the location of the windows, and indeed their presence, with just one click of the mouse, as they say Drag&Drop. I settled on this system, as I quickly set notifications about tickets to mail, and maybe also to SMS. Wonderful work with the material base (inventory of IT system equipment), with reference to the user, which in turn are imported from Active Directory or LDAP. Also, standard authorization can be supplemented without much difficulty with domain authorization and leave the user the ability to choose a login method.
The only thing is that there is no good unofficial site for more than one system :(
If anything, write to the topic on ru-board, we will share our experience of using it.
I hope this article will help you save some of that precious time, which is better spent studying the history of the endangered Crimean people of the Krymchak ethnic group.
Good luck to all!
PS (after 2 years): At the moment I'm using OTRS 3.1.3 for receiving, processing tickets (ticket) and happy with my choice.
Pros:
- works fast (Linux)
- highly customizable reports
- about 1300 advanced system configuration sections with full-text search on them
- no problem updating a running system
- hot buttons
- due to such an abundance of advanced settings sections, it is sometimes very difficult to find the right one
- I could not set it up so that when answering a request, the default status would be "closed successfully"
- could not reduce the size of the text field for entering the content of the application when responding to the application (the "Reply" button does not fit in the newly opened window).
So what is OTRS?
As the name "Open source Ticket Request System" implies, OTRS is a system for accounting (receiving and processing) applications (tickets). Under the application (ticket) I understand the appeal of someone to someone. Thus, the possibilities of using OTRS are much wider than Helpdesk in the IT department. For example, the ideology of the system perfectly fits the work of the support department for anything, the work of the sales department to receive requests for issuing a commercial offer or invoice, the work of the quality control service, etc. But for now, I would like to limit myself to the IT department, whose Helpdesk service I would like to automate, so the following description will describe solutions specifically for Helpdesk.
What tasks is designed to solve OTRS for Helpdesk:
- Registration of appeals. IT staff need to know what the call was; users need to understand that the appeal has reached the address and is not lost. In addition, it is convenient for the user that any requests can be processed in the same unified way.
- Accounting and processing of appeals. IT staff must know what calls are available at any given moment and take action to fulfill them; users need to understand what is going on with their message.
- Automation of order fulfillment. There is a thesis that any problem can be solved by a competent specialist within 1 hour. It is only necessary that the problem immediately fall into the hands of such a specialist. Therefore, if you automate the processing of incoming requests, you can drastically shorten the path to contacting the appropriate specialist.
- Fight against "Secret Knowledge". Information on applications and actions on applications should be recorded so that it is known NOT only to the employee who undertook its implementation. Otherwise, the execution of applications may stumble over the human factor, and the application will not be executed because they simply do not know about it, although there are more than enough people who could fulfill it.
The ideology of the system implies that any appeal must be recorded. Appeals are recorded in the form of an application. In order to avoid misunderstandings, I would like to introduce some basic concepts:
- The client is the one who forms the application. This is an external user of the system.
- Agent - the one who processes the application. This is an internal user of the system.
Fixing a request is the identification of the Client, assigning a unique number to the application and pre-processing in order to categorize the request and notify the Agent (s) about a new application.
Applications are placed in queues.
- Queue - the location of the request.
Queues allow:
- Divide the total array of applications.
- Provide different access for Agents to applications.
- Notify certain Agents about events with an application.
- Set up various automatic responses to Clients depending on the parameters of the request
How do applications appear in the system? 3 ways are offered:
- Email message. OTRS checks the mailbox(es) and turns each message into a ticket
- Filling out the form by the Client through the web interface
- Creation of an application by the Agent on the basis of a personal request, for example, by phone or in words in a smoking room.
Let's break this for now. The next article will be devoted to a brief description of the installation experience and a more detailed description of the initial system setup.
(O pen source T icket R request S ystem is an open ticketing system that provides a single point of contact for users, IT staff, IT services, and any external organization. The program is written in Perl. OTRS supports many databases (MySQL, PostgreSQL, etc.) and integration with LDAP directories.
This guide will help you install and configure OTRS on a CentOS 7 server.
Requirements
- CentOS 7 server;
- Non-root user with sudo access (read about user privileges here);
- 4 GB of swap space (more on setting up swap in this guide).
Step 1 Install MariaDB
First you need to install all OTRS dependencies.
To do this, you need the EPEL (Extra Packages for Enterprise Linux) repository. Add it:
sudo yum install epel-release
Update system:
Install MariaDB (a fork of MySQL):
sudo yum install mariadb-server mariadb
For OTRS to work correctly, you need to change the default MySQL settings. Open the configuration file in the vi editor:
sudo vi /etc/my.cnf
Add the following lines to the section, which define the sizes of some files:
max_allowed_packet = 20M
query_cache_size = 32M
innodb_log_file_size = 256M
datadir=/var/lib/mysql
. . .
Save and close the file.
Note Note: These changes must be made before starting MySQL.
Start MariaDB:
sudo systemctl start mariadb.service
Run a MySQL script that will remove all unsafe options.
sudo mysql_secure_installation
The script will ask a few questions. To accept the default values, simply press Enter. Be sure to change only the standard root password. Choose a strong password.
Step 2: Installing OTRS
You can install OTRS using a precompiled RPM package. Download this package from the official program repository.
Note A: Before downloading a package, make sure it is the latest version.
wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-5.0.7-01.noarch.rpm
Install OTRS:
sudo yum install otrs-5.0.7-01.noarch.rpm
The OTRS program is written in Perl, so some Perl modules are required to run it. To determine the missing modules, use the CheckModules.pl script (it comes with the OTRS package):
sudo /opt/otrs/bin/otrs.CheckModules.pl
The output looks something like this:
o Apache::DBI......................ok (v1.12)
o Apache2::Reload.............FAILED! Not all prerequisites for this module correctly installed.
. . .
o XML::LibXSLT......................ok (v1.80)
o XML::Parser......................ok (v2.41)
o YAML::XS......................Not installed! Use: "yum install "perl(YAML::XS)"" (required - Very important)
Some modules are needed only for additional functions (for example, to communicate with other databases or to process mail with Chinese characters). To install the missing modules, use the yum commands suggested in the output.
sudo yum install "perl(Apache2::Reload)" "perl(Crypt::Eksblowfish::Bcrypt)" "perl(Encode::HanExtra)" "perl(JSON::XS)" "perl(Mail::IMAPClient) " "perl(ModPerl::Util)" "perl(Text::CSV_XS)" "perl(YAML::XS)"
After installing all the necessary modules, run the script again to make sure that all requirements are met.
Step 3: Setting up OTRS
Now you need to configure the database and OTRS mail. First restart Apache to update the settings with the OTRS settings.
sudo systemctl restart httpd.service
Now open the installer web page:
http://your_server_ip/otrs/installer.pl
The welcome page will appear on the screen. Click Next. After that, you need to accept the license; read it and click Accept license and continue.
On the next page, you need to select a database. Select MySQL from the dropdown menu and click Create a new database for OTRS (typically MySQL is selected by default). Click Next.
After that, you need to specify the previously created MySQL database credentials. To make sure the data is correct, click Check database settings.
The installer will generate credentials for the new database. You don't need to remember this generated password as you won't need it later, so just click Next to continue. After that, the installer will create a new database. Click Next.
After that, you need to specify the system parameters:
- FQDN: The domain name or IP address of the server.
- Admin Email: System administrator's email address. This is where the program will send error notifications.
- Organization: The name of the organization.
The rest of the default settings can be left unchanged.
To be able to receive emails from users, you need to set up incoming mail.
Locate the Configure Inbound Mail section and provide the required credentials. For example, if you use the Google mail provider, you can create an app password and enter the following details:
- Inbound mail type: IMAPS
- Inbound mail host: imap.gmail.com
- Inbound mail user: your_email_address
- Inbound mail password: your_app_password
To check the configuration, click the corresponding button. Within a few seconds, the following message will appear:
Mail check successful
Press OK to go to the last screen.
OTRS installation and configuration is complete!. A link to access the admin toolbar and superuser credentials will appear on the screen.
Important! Don't forget to write down the generated password for the root@localhost user and the URL of the start page.
Now it remains only to start the OTRS daemon and enable its cronjob:
sudo su -otrs -c "/opt/otrs/bin/otrs.Daemon.pl start"
sudo su -otrs -c "/opt/otrs/bin/Cron.sh start"
4: OTRS Protection
At this point, you have a fully functional application. However, using a superuser account with OTRS is not safe. Therefore, it is necessary to create a new agent.
In OTRS, agents are users who have access to system functions. In this example, we will create one agent that will have access to all OTRS features.
To create a new agent, log in as root@localhost. Open the link you received at the end of the installation and enter the username root@localhost and password (see end of section 3).
The main panel will appear on the screen. It contains several widgets that show various ticket information, statistics, news, etc. You can freely position them by drag and drop or disable them in the settings.
First you need to create a new agent. At the top of the control panel there will be a warning highlighted in red:
Don't use the Superuser account to work with OTRS! Create new Agents and work with these accounts instead. →
To create a new agent, click on this message and then click Add agent. A number of fields will appear on the screen. Fortunately, filling out all of these fields is optional - most of the default options work. You only need to fill in the fields First Name, Last Name, Username, Password and Email.
After that, you need to change the group relations of the new agent. The new agent will also be an administrator, so he needs read and write permissions in all groups. To do this, check the box next to RW in the Change Group Relations for Agent settings.
Click Submit. Now you can log out of the superuser account and use the new agent to run. By clicking on the gear icon in the upper left corner of the screen, you can change the agent's settings (change the password, select the interface language, configure notifications, queues, interface theme, and much more).
Step 5: Manage Tickets
Now let's look at ticket management. Customers can submit tickets to OTRS in two ways: using the interface or via email.
http://your_server_ip/otrs/customer.pl
Here you can create a user account and submit a ticket.
You can also create a new ticket by sending an email to the email address provided during setup. By default, all tickets received by mail are stored in the same queue and have normal priority. All customer tickets can be viewed in the customer web interface, regardless of how they were submitted.
All new tickets created using the interface will immediately appear on the agent's dashboard. Tickets sent by mail may not immediately appear on the dashboard because OTRS checks for new tickets every 10 minutes.
On the agent's dashboard, you can find information about all current tickets: their status (new, open, escalation, etc.), their "age" (time elapsed since the ticket was received), and subject.
To view ticket details, you can click on its number in the Ticket # column. In this window, the agent can also interact with the ticket (change its priority or state, move it to another queue, close it, and so on).
Note: Learn more about the OTRS program in the official guide.
Tags: ,
Loading...