The script will return the number of used queues per ticket. The number of moves is this number less 1.

You need to activate the SOAP Interface via SysConfig first!

#!/usr/bin/perl -w
# SOAP Config
use SOAP::Lite( 'autodispatch', proxy => 'http://otrsserver/otrs/rpc.pl' );
my $SOAP_User = 'otrs';
my $SOAP_Pass = 'test';
 
# getting TicketID
use Getopt::Std;
my %opts;
getopts( 'i:', \%opts );
if ( !$opts{i} ) {
    print STDERR "ERROR: Need -i TicketID\n";
    exit 1;
}
# SOAP script
my $RPC = Core->new();
 
my @QueueList = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'MoveQueueList',
        TicketID => $opts{i},
        Type     => 'Name',
    );
my $TicketNumber = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'TicketNumberLookup',
        TicketID => $opts{i},
    );
$QL = scalar @QueueList;
print "NOTICE: Ticket#$TicketNumber ($opts{i}) - number of moves is $QL\n";
exit 0;

Running it  will look like this:


jb$ ./rpc_getmove.pl -i 4
NOTICE: Ticket#2010010610000011 (4) - number of moves is 8


Now the complete script for the “Hot Potatoes”


jb$ ./rpc_getmove-hot-potatoe.pl -m 6
NOTICE: Ticket#2010010610000011 (4) - number of used Queues: 8 - Limit: 6


The option -m defines the max. number of allowed Queues. If the number of used Queues for the ticket is greater than this value, the Ticketnumber will be given by the script on STDOUT..

You’ll find some more options for TicketSearch on the API description.

You’ll need to activate the SOAP interface of OTRS via SysConfig first. Perl SOAP::Lite will be needed by this script.

#!/usr/bin/perl -w
# SOAP Config
use SOAP::Lite( 'autodispatch', proxy => 'http://otrsserver/otrs/rpc.pl' );
my $SOAP_User = 'otrs';
my $SOAP_Pass = 'test';
 
# getting TicketID
use Getopt::Std;
my %opts;
getopts( 'm:', \%opts );
if ( !$opts{m} ) {
    print STDERR "ERROR: Need -m Maximum Queues\n";
    exit 1;
}
# SOAP script
my $RPC = Core->new();
 
# Getting all Open Tickets
my @TicketIDs = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'TicketSearch',
        Limit  => 100000,
        Result => 'ARRAY',
        UserID => 1,
#       Queues   => ['system queue', 'other queue'],
#       UseSubQueues => 1,
        StateType    => ['open', 'new', 'pending reminder'],
    );
 
# Start of for statement
for my $TicketID (@TicketIDs) {
        my @QueueList = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'MoveQueueList',
                TicketID => $TicketID,
                Type     => 'Name',
        );
        my $TicketNumber = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'TicketNumberLookup',
                TicketID => $TicketID,
        );
        $QL = scalar @QueueList;
        if ( $opts{m} < $QL )
                {
                print "NOTICE: Ticket#$TicketNumber ($TicketID) - number of used Queues: $QL - Limit: $opts{m}\n";
                }
}
exit 0;

The OTRS dashboard can be extended quite easy. Some of the existing widgets can be used  more then once.

An easy example is an additional RSS feed.

The “Heise Newsticker” should be displayed below the OTRS.org newsfeed in the dashboard.

Just insert in Config.pm the following code:

$Self->{'DashboardBackend'}->{'0415-RSS'} =  {
'Block' => 'ContentSmall',
'CacheTTL' => '600',
'Default' => '1',
'Description' => 'Heise Newsticker',
'Group' => '',
'Limit' => '5',
'Module' => 'Kernel::Output::HTML::DashboardRSS',
'Title' => 'Heise News',
'URL' => 'http://www.heise.de/newsticker/heise-atom.xml'
};

I like to keep an eye on everything that’s happening on Twitter with regards to OTRS. Just yesterday I saw this:

For all of you that aren’t really into German – such as myself, I’m still learning… – what the guy said you can translate as “Today I learned about OTRS: you can expand all articles if you press the Print button. People find that smart.”

Then there was this smart-ass reply:

Which you can translate as “So then, how do you print? By clicking Expand all articles?”

Besides all this twitter-fun I must admit that usability in OTRS 2.4 is not top-notch and has room for improvement. That’s the reason our R&D team is working so hard to put together OTRS 3, and for that we’ve called in the aid of usability specialists to make sure that it is not just developers that put together a working help desk system, but that it also works as one would expect. This makes OTRS have a lower learning curve for new users.

And while printing the ticket is one way to show all articles, there is an Expand all articles button in OTRS 2.4 present, you just have to know where it’s at. It’s a small icon that you find just underneath the list of articles, on the right hand side. I’ve highlighted it in the screenshot below. If you hover over it, it’ll show a tooltip with the text Expand View.

And in upcoming version 3 it will look different; there will be two icons in the bar above the list of articles, and the active one will be selected. I highlighted the icons in the screenshot below. The leftmost icon is to display just one article and the other icon is for displaying all articles. Please note that work on version 3 is still ongoing and that the screenshot below will not be definitive. Having said that, we still do appreciate your feedback of course!

I hope my post explained that we do have a proper option to expand all articles, and that we are working hard to bring more usability into our product. And of course, all of your suggestions on how to make it even better are more then welcome! And for those of you who like Twitter, such as @mchlpchl and @Brainvibes: you can follow me on @otrsnl.

The OTRS Dashboard can show external pictures already. The backport of the Dashboard IFrame Plugin from the upcoming version 3.0 could be used to display a complete webpage or other content like a flashplayer.

So you could use it to display the menue from you favorite restaurant, an external admin tool or external reports.

Nützlich z.B. um externe Admintools, Reports, Speisekarte der Kantine oder alles andere was einem in den Sinn kommt einzubinden…

You’ll find the backport for the 2.4 here: DashboardIFrame-0.0.1.opm

Additional to the described way in the article “additional RSS feed in the dashboard” there is a much more convient way via SysConfig: Framework -> Frontend::Agent::Dashboard

To get the additional feeds you have to provide some special configuration to the SysConfig. A XML file, including the default values needs to be placed in the directory Kernel/Config/Files

CustomRSS.xml (rename file to CustomRSS.xml !)

This post is about a customer’s request:

Hi, maybe you can help me please.
I have a common queue for all calls, I would like to create an ACL where a specific group can see only tickets for a single customer on StatusView. [...]

Well, no, that’s not possible via ACL as you can’t hide tickets from an agent with ACL. But there are two (hopefully equal) options for you – use a saved search profile or add your own plugin to the Dashboard.

Use a customized search

The easy solution – each agent has the option to save a search profile as a template for later re-use:

Save the search profile

Use the saved search profile

Now we want a quick access to this search profile from everywhere inside the OTRS and thus enable access to search-profiles from the navigation bar via the SysConfig

Ticket -> Frontend::Agent::NavBarModule
  Frontend::NavBarModule###1-Ticket::TicketSearchProfile:
  Agent interface module to access search profiles via nav bar.

Search profiles in the navigation bar

Use a customized Dashboard plugin

Now the more challenging but nicer option – add your own Dashlet to the Dashboard.

The known Dashlets “Reminder Tickets”, “Escalated Tickets”, etc. are in fact ticket searches performed for each Agent calling the Dashboard. The searches are defined initially in an XML file and can be altered via the SysConfig interface later on.

Step 1 – create your own XML file

OTRS delivers its default configuration as XML files which are placed to

Kernel/Config/Files

The Dashboard description is part of the Ticket area and can be found in Ticket.xml (just search for Dashboard in the file).

We create our own configuration file, name it MyConfig.xml and add the necessary XML container to the file:

<?xml version="1.0" encoding="utf-8"?>
 <otrs_config version="1.0" init="Application">
</otrs_config>

Step 2 – copy & paste a Dashlet

From the mentioned Ticket.xml we get the description of a Dashlet e.g. “Open Tickets” and paste it to our file which should then look like this:

<?xml version="1.0" encoding="utf-8"?>
 <otrs_config version="1.0" init="Application">
  <ConfigItem Name="DashboardBackend###0130-TicketOpen" Required="0" Valid="1">
  <Description Lang="en">Parameters  for the dashboard backend. ...</Description>
  <Description Lang="de">Parameter  für das Dashboard Backend. ... </Description>
  <Group>Ticket</Group>
  <SubGroup>Frontend::Agent::Dashboard</SubGroup>
  <Setting>
   <Hash>
    <Item Key="Module">Kernel::Output::HTML::DashboardTicketGeneric</Item>
    <Item Key="Title">Open Tickets / Need to be answered</Item>
    <Item Key="Description">Tickets which need to be answered!</Item>
    <Item Key="Attributes">StateType=open;</Item>
    <Item Key="Filter">All</Item>
    <Item Key="Time">Age</Item>
    <Item Key="Limit">10</Item>
    <Item Key="Permission">rw</Item>
    <Item Key="Block">ContentLarge</Item>
    <Item Key="Group"></Item>
    <Item Key="Default">1</Item>
    <Item Key="CacheTTLLocal">0.5</Item>
   </Hash>
  </Setting>
 </ConfigItem>
</otrs_config>

Step 3 – modify the configuration to your needs

The interesting parts are

• Attributes – the parameters to AgentTicketSearch()
• Filter – which tickets should be considered
• Time – which time should be shown in the Dashlet
• Limit – how many tickets should be shown per screen
• Permissions – which permissions does the agent need on a ticket so it gets shown
• Group – which group (and through Roles – which Agent) should see this Dashlet
• Default – is the Dashlet activated by default or optional for the Agent
• CacheTTLLocal – how often should the content be refreshed (in minutes)

As I stated earlier, the Dashlets are just a ticket search. If you have a look at the Attributes of the Dashlet “Reminder Tickets” – <Item Key=”Attributes”>TicketPendingTimeOlderMinutes=1;StateType=pending reminder;SortBy=PendingTime;OrderBy=Down; </Item> – you get an impression what could be possible.

The AgentTicketSearch() function is described in the Developer manual [AgentTSearch].

The Filter is one of the following values

• Locked
• Watcher
• Responsible
• MyQueues
• All

The Time can be one out of these settings

• Age
• UntilTime
  (for pending states)
• General escalation info of nearest escalation type
  • EscalationTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800″
  • EscalationTime
    (seconds total till escalation of nearest escalation time type – response, update or solution time, e. g. “3600″)
• Detail escalation info about first response, update and solution time
  • FirstResponseTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800″)
  • FirstResponseTime
    (seconds total till escalation, e. g. “3600″)
  • UpdateTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800″)
  • UpdateTime
    (seconds total till escalation, e. g. “3600″)
  • SolutionTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800″)
  • SolutionTime
    (seconds total till escalation, e. g. “3600″)

For the initial request we just need the CustomerID, the open/new state and a permission group. Please also change the name and position of the Dashlet!

So here’s the final myConfig.xml

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="1.0" init="Application">
 <ConfigItem Name="DashboardBackend###0600-TicketCustomerABC" Required="0" Valid="1">
  <Description Lang="en">Parameters  for the dashboard backend. ...</Description>
  <Description Lang="de">Parameter  für das Dashboard Backend. ...</Description>
  <Group>Ticket</Group>
  <SubGroup>Frontend::Agent::Dashboard</SubGroup>
  <Setting>
   <Hash>
    <Item Key="Module">Kernel::Output::HTML::DashboardTicketGeneric</Item>
    <Item Key="Title">Tickets for Customer ABC</Item>
    <Item Key="Description">All tickets for customer ABC</Item>
    <Item Key="Attributes">CustomerID=foobar.inc;StateType=open;StateType=new;</Item>
    <Item Key="Filter">All</Item>
    <Item Key="Time">Age</Item>
    <Item Key="Limit">10</Item>
    <Item Key="Permission">rw</Item>
    <Item Key="Block">ContentLarge</Item>
    <Item Key="Group">G_CustomerABC</Item>
    <Item Key="Default">1</Item>
    <Item Key="CacheTTLLocal">5</Item>
   </Hash>
  </Setting>
 </ConfigItem>
</otrs_config>

Step 4 – apply the new setting to the system

Simply run
perl bin/otrs.RebuildConfig.pl
and you have the new Dashlet definition available in your SysConfig

Ticket -> Frontend::Agent::Dashboard
DashboardBackend###0600-TicketCustomerABC

Configuration via SysConfig

and your Dashboard

Our example Dashlet

Further Reading

[AgentTSearch] – http://dev.otrs.org/2.4/Kernel/System/Ticket.html#item_ticketsearch

You all know the need of our agents to have Ticket-Template-Buttons in Phone and Email View.
This is of course not as good as it could be, because you need to modify standard *.dtl files. Therefore you actually need to change something that is not update save.

but …

NOW THERE IS OTRS 3.0 !!!

AgentNavigationBar

If you hit this new created navigation item you are redirected to the normal phone ticket view, but the page is magically prefilled with content. The content can be the default Queue for requests regarding software, the ticket type for incidents, a meaningful subject and body … maybe with a checklist … open your mind and create your own templates

This is the resulting screen – just as an example:

AgentTicketPhone

But how does this magic works???

Simple answer: by extending options in the OTRS 3.0 SysConfig

You need it more specific? Here we go:

|-> SysConfig

|-> Ticket

|-> Frontend::Agent::ModuleRegistration

|-> Frontend::Module###AgentTicketPhone

There you just need to add a new SysConfig hash where you can describe additional menu entries with URL params as you want.

Adding a new hasg is simply done by clicking on theplus sign on the bottom.

My  configuration for the screens above:

AdminSysConfigEdit

Where the Action Param is:

Action=AgentTicketPhone;Subaction=StoreNew;ExpandCustomerName=2;Subject=Example+Subject;Dest=1%7C%7CPostmaster;NextStateID=4;TimeUnits=5;Body=%3Cstrong%3E%3Cspan+style%3D%22color%3A+rgb%28255%2C+0%2C+0%29%3B%22%3EMy+bonnie+is+over+the+ocean%3C%2Fspan%3E%3C%2Fstrong%3E%2C+%3Cspan+style%3D%22color%3A+rgb%28230%2C+230%2C+250%29%3B%22%3E%3Cspan+style%3D%22background-color%3A+rgb%280%2C+0%2C+255%29%3B%22%3Emy+bonnie+is+over+the+sea%3C%2Fspan%3E%3C%2Fspan%3E%2C+%3Cspan+style%3D%22color%3A+rgb%280%2C+128%2C+0%29%3B%22%3E%3Cspan+style%3D%22font-size%3A+16px%3B%22%3E%3Cspan+style%3D%22font-family%3A+Comic+Sans+MS%2Ccursive%3B%22%3E%3Cem%3E%3Cu%3Eoh+bring+back+my+bonnie+to+me%3C%2Fu%3E%3C%2Fem%3E%3C%2Fspan%3E%3C%2Fspan%3E%3C%2Fspan%3E!%3Cbr+%2F%3E%0D%0A

Define the ticket’s options, all are optional as argument for
“Action=AgentTicketPhone;Subaction=StoreNew”

Remember to encode everything non-ASCII (even a SPACE is represented as ‘+’)

http://en.wikipedia.org/wiki/Percent-encoding

Subject      : Subject=Example+Subject
Target queue : Dest=1%7C%7CPostmaster  (means: 1||Postmaster)
Next state   : NextStateID=4           (check your configuration for valid state IDs)
Time units   : TimeUnits=5
Type         : TypeID=1                (check your configuration for valid type IDs)
Service      : ServiceID=5             (check your configuration for valid service IDs)
Priority     : PriorityID=3            (check your configuration for valid priority IDs)
...

Hint:

To find valid values for the above xxIDs, please have a look into the Admin interface or the source of a generated website.

And there is more power !!! Unlike other systems, you can now define permission groups for EACH template. This enables you to provide IT related ticket templates to your IT Department guys and HR related templates to your HR guys … again, open your mind … to OTRS 3.0!

Have phun with OTRS 3.0

A question asked by my customers quite often is:

“How can we create a reoccuring ticket for tasks like checking the backup?”

As there was no solution inside of the OTRS Framework yet my answer was:

“Sorry, you have to create an e-mail via cron for this.”

An article in the german Linux Magazin put this question back to my mind. (Sorry it is in german..)

So I changed the script ‘ical-daemon’ to my needs. Now the following parameters of the ical file are used:
The ticket itself is created by the script ‘create-ticket.pl’ which will be triggered by ‘ical-daemon’ with the needed parameters.

Ticket created by the daemon:

Example ics file:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//iCal 4.0.3//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T020000
TZNAME:GMT+02:00
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T030000
TZNAME:GMT+01:00
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20101111T190648Z
UID:6B58179D-E1C4-466B-A881-F15A663EE4A7
DTEND;TZID=Europe/Berlin:20101111T225000
TRANSP:OPAQUE
SUMMARY:Please check Backup
DTSTART;TZID=Europe/Berlin:20101111T230000
DTSTAMP:20101111T202135Z
LOCATION:Postmaster
SEQUENCE:7
DESCRIPTION:Please check Backup of the following servers:
- server 1
- server 2
- server 3
END:VEVENT
END:VCALENDAR

The modified ical-daemon script:


#!/usr/bin/perl -w
###########################################
# ical-daemon - Parse .ics files and send
#               alerts on upcoming events.
# Mike Schilli, 2010 (m@perlmeister.com)
# modified by Jens Bothe (jb@otrs.org)
###########################################
use strict;
#use local::lib;
use iCal::Parser;
use Log::Log4perl qw(:easy);
use App::Daemon qw(daemonize);
use Sysadm::Install qw(mkd slurp tap);
use FindBin qw($Bin);

our $UPDATE_REQUESTED = 0;
our $ALERT_BEFORE =
DateTime::Duration->new( minutes => 15 );
our $CURRENT_DAY      = DateTime->today();
our @TODAYS_EVENTS    = ();

my($home)  = glob "~";
my $admdir = "$home/.ical-daemon";
my $icsdir = "$admdir/ics";

mkd $admdir unless -d $admdir;
mkd $icsdir unless -d $icsdir;

$App::Daemon::logfile = "$admdir/log";
$App::Daemon::pidfile = "$admdir/pid";

if( exists $ARGV[0] and
$ARGV[0] eq '-q' ) {
my $pid = App::Daemon::pid_file_read();
kill 10, $pid; # Send USR1
exit 0;
}

Log::Log4perl->easy_init({
level => $DEBUG,
file  => $App::Daemon::logfile
});

$SIG{ USR1 } = sub {
DEBUG "Received USR1";
$UPDATE_REQUESTED = 1;
};

$UPDATE_REQUESTED = 1; # bootstrap

daemonize();

while(1) {
my $now = DateTime->now(
time_zone => 'local' );

my $today =
$now->clone->truncate( to => 'day' );

if( $UPDATE_REQUESTED or
$CURRENT_DAY ne $today ) {

$UPDATE_REQUESTED = 0;
$CURRENT_DAY      = $today;

DEBUG "Updating ...";
@TODAYS_EVENTS    = update( $now );
DEBUG "Update done.";
}

if( scalar @TODAYS_EVENTS ) {
my $entry         = $TODAYS_EVENTS[0];

DEBUG "Next event at: $entry->[0]";

if( $now >
$entry->[0] - $ALERT_BEFORE ) {
INFO "Notification: ",
"$entry->[1] $entry->[0]";
#      tap "$Bin/ical-notify", $entry->[2], $entry->[1],
tap "$Bin/create-ticket.pl", $entry->[2], $entry->[1], $entry->[3],
$entry->[0];
shift @TODAYS_EVENTS;
next;
}
}

DEBUG "Sleeping";
sleep 60;
}

###########################################
sub update {
###########################################
my($now) = @_;

my $start = $now->clone->truncate(
to => 'day' );
my $tomorrow = $now->clone->add(
days => 1 );

my $parser=iCal::Parser->new(
start => $start,
end   => $tomorrow );

my $hash;

for my $file (<$icsdir/*.ics>) {
DEBUG "Parsing $file";
$hash = $parser->parse( $file );
}

my $year  = $now->year;
my $month = $now->month;
my $day   = $now->day;

if(! exists $hash->{ events }->{
$year }->{ $month }->{ $day } ) {
return ();
}

my $events = $hash->{ events }->{
$year }->{ $month }->{ $day };

for my $key ( keys %$events ) {
if( event_is_holiday(
$events->{ $key } ) ) {
WARN "No alerts today (holiday)";
return ();
}
}

my @events = ();

for my $key ( keys %$events ) {
next if $now >
$events->{ $key }->{ DTSTART };
# already over?

push @events, [
$events->{ $key }->{ DTSTART },
$events->{ $key }->{ DESCRIPTION },
$events->{ $key }->{ SUMMARY },
$events->{ $key }->{ LOCATION },
];
}

@events = sort { $a->[0] <=> $b->[0] }
@events;

return @events;
}

###########################################
sub event_is_holiday {
###########################################
my($event) = @_;

return undef unless
exists $event->{ ATTENDEE };

if( $event->{ ATTENDEE }->[ 0 ]->{ CN }
eq "US Holidays" ) {
return 1;
}
return 0;
}

Script: create-ticket.pl

#!/usr/bin/perl -w

use SOAP::Lite( 'autodispatch', proxy => 'http://otrs-server/otrs/rpc.pl' );
my($subject, $agenda, $queue, $time) = @ARGV;
my $SOAP_User = 'otrs_test';
my $SOAP_Pass = 'test_otrs!';

my $OTRS_Subject = $subject;
my $OTRS_Body = $agenda;

my $OTRS_CustomerFrom = 'feedback@otrs.org';
my $OTRS_Queue = $queue;

# script
my $RPC = Core->new();

# create a new ticket number
my $TicketNumber = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'TicketCreateNumber' );
#print "NOTICE: New Ticket Number is: $TicketNumber\n";
# create a new ticket
my %TicketData = (
TN           => $TicketNumber,
Title        => $OTRS_Subject,
Queue        => $OTRS_Queue,
Lock         => 'unlock',
Priority     => '3 normal',
State        => 'new',
CustomerID   => $OTRS_CustomerFrom,
CustomerUser => $OTRS_CustomerFrom,
OwnerID      => 3,
UserID       => 3,
);
my $TicketID = $RPC->Dispatch( $SOAP_User, $SOAP_Pass, 'TicketObject', 'TicketCreate', %TicketData => 1 );
#print "NOTICE: TicketID is $TicketID\n";

# create new article
my $ArticleID = $RPC->Dispatch($SOAP_User, $SOAP_Pass, 'TicketObject', 'ArticleCreate',
TicketID         => $TicketID,
ArticleType      => 'phone',                # email-external|email-internal|phone|fax|...
SenderType       => 'customer',             # agent|system|customer
From             => $OTRS_CustomerFrom,     # not required but useful
To               => $OTRS_Queue,            # not required but useful
ReplyTo          => $OTRS_CustomerFrom,     # not required
Subject          => $OTRS_Subject,          # required
Body             => $OTRS_Body,             # required
Charset          => 'utf-8',
HistoryType      => 'PhoneCallCustomer',    # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|...
HistoryComment   => 'Customer called us.',
UserID           => 3,
NoAgentNotify    => 0,                      # if you don't want to send agent notifications
MimeType         => 'text/plain',
Loop             => 0,                      # auto reject|auto follow up|auto follow up|auto remove
AutoResponseType => 'auto reply',
ForceNotificationToUserID => '',
OrigHeader       => {
'From' => $OTRS_CustomerFrom,
'To'   => $OTRS_Queue,
'Subject' => $OTRS_Subject,
'Body' => $OTRS_Body,
},
);
#print "NOTICE: ArticleID is $ArticleID\n";

exit 0;

You can download the files here

Recently a customer had a very interesting issue which he needed to be solved. For external visitors they provide a free WIFI protected by an WPA key. They created some scripts to generate the key and distribute it to the access points.

Internal customers can order access for their guests at the IT guys. As OTRS now is used for tracking all kind of requests they decided to send out the confirmation mail including the key via OTRS. As a “geek goody” they also wanted to create a QR Code for the WIFI data, which looks like this:

We created the following items to make this happen:
- a shell script for generation of an OTRS config file which gets the key as parameter
- a default response using the variable stored in the config file. This variable is called notification tag in OTRS.

The shell script:

#!/bin/sh
Key="$1";
echo "\$Self->{'WEPKey'} = '$Key';" > /otrs/Kernel/Config/Files/WIFI.pm;
echo "1;" >> /otrs/Kernel/Config/Files/WIFI.pm;

The notification tag for this in OTRS is: <OTRS_CONFIG_WEPKey>

The content of the response (you need to type in the data as HTML Source!)

Writing the answer to the customer will look like this:

Some more informations:

• OTRS Notification Tags
• 2D Barcode explanation
• Google API description

Shawn created a nice video on using the Firefox Plugin Cool Preview for even more productivity with OTRS

I just wanted to show this very nice video my colleague Shawn made on the topic of making the most out of the OTRS Ticket Search dialog. He shows how to use ticket search templates, how to extend the search dialog with your own fields and how to extend your browser to search in OTRS very quickly.

You can probably best watch the video on full screen.

The actual discussion on  possible unwanted readers of your mails shows the need to encrypt emails. OTRS has the possibility to sign and encrypt via S/MIME and PGP/GnuPG.

For enabling PGP only a few steps are needed. So this post shows how to setup PGP on your system.

Step 1 – Install GnPG

Step 2 – Create a key:

Enter the following command in your shell and follow the instructions

gpg --gen-key

Step 3 – Export Key:

gpg --export -a > public.asc
gpg --export-secret-key -a > private.asc

Step 4 – Activate PGP in sysconfig:

Step 5 – Upload Keys:

You have to upload the public and the private key. Please ensure that you are using the Key ID of the secret key within Crypt::PGP for assigning the password! You also should be sure that the .gnupg directory was created and is assigned to the webserver user (thats why it is suggested to run the webserver with the OTRS user!) You can also have a look at the documentation for more hints.

Step 6 – Upload Customer Public Keys:

For encryption of emails to customers and verifying signatures OTRS needs the public key of your customer users stored. They can be uploaded via Customer Interface or the customer management screen in agent interface.

Step 7 – Work with signed and encrypted mails

Now we can send and receive signed and encrypted mails

Reply encrypted:

Verify changed mails:

Happy ((encrypting))

Giovanni, who uses OTRS in his security team wrote a nice article in his blog:

Thanks for the great work Giovanni :-)

This post is about a customer’s request:

Hi, maybe you can help me please. :)
I have a common queue for all calls, I would like to create an ACL where a specific group can see only tickets for a single customer on StatusView. […]

Well, no, that’s not possible via ACL as you can’t hide tickets from an agent with ACL. But there are two (hopefully equal) options for you – use a saved search profile or add your own plugin to the Dashboard.

Use a customized search

The easy solution – each agent has the option to save a search profile as a template for later re-use:

Save the search profile

Use the saved search profile

Now we want a quick access to this search profile from everywhere inside the OTRS and thus enable access to search-profiles from the navigation bar via the SysConfig

Ticket -> Frontend::Agent::NavBarModule
  Frontend::NavBarModule###1-Ticket::TicketSearchProfile:
  Agent interface module to access search profiles via nav bar.

Search profiles in the navigation bar

Use a customized Dashboard plugin

Now the more challenging but nicer option – add your own Dashlet to the Dashboard.

The known Dashlets “Reminder Tickets”, “Escalated Tickets”, etc. are in fact ticket searches performed for each Agent calling the Dashboard. The searches are defined initially in an XML file and can be altered via the SysConfig interface later on.

Step 1 – create your own XML file

OTRS delivers its default configuration as XML files which are placed to

Kernel/Config/Files

The Dashboard description is part of the Ticket area and can be found in Ticket.xml (just search for Dashboard in the file).

We create our own configuration file, name it MyConfig.xml and add the necessary XML container to the file:

<?xml version="1.0" encoding="utf-8"?>
 <otrs_config version="1.0" init="Application">
</otrs_config>

Step 2 – copy & paste a Dashlet

From the mentioned Ticket.xml we get the description of a Dashlet e.g. “Open Tickets” and paste it to our file which should then look like this:

<?xml version="1.0" encoding="utf-8"?>
 <otrs_config version="1.0" init="Application">
  <ConfigItem Name="DashboardBackend###0130-TicketOpen" Required="0" Valid="1">
  <Description Lang="en">Parameters  for the dashboard backend. ...</Description>
  <Description Lang="de">Parameter  für das Dashboard Backend. ... </Description>
  <Group>Ticket</Group>
  <SubGroup>Frontend::Agent::Dashboard</SubGroup>
  <Setting>
   <Hash>
    <Item Key="Module">Kernel::Output::HTML::DashboardTicketGeneric</Item>
    <Item Key="Title">Open Tickets / Need to be answered</Item>
    <Item Key="Description">Tickets which need to be answered!</Item>
    <Item Key="Attributes">StateType=open;</Item>
    <Item Key="Filter">All</Item>
    <Item Key="Time">Age</Item>
    <Item Key="Limit">10</Item>
    <Item Key="Permission">rw</Item>
    <Item Key="Block">ContentLarge</Item>
    <Item Key="Group"></Item>
    <Item Key="Default">1</Item>
    <Item Key="CacheTTLLocal">0.5</Item>
   </Hash>
  </Setting>
 </ConfigItem>
</otrs_config>

Step 3 – modify the configuration to your needs

The interesting parts are

• Attributes – the parameters to AgentTicketSearch()
• Filter – which tickets should be considered
• Time – which time should be shown in the Dashlet
• Limit – how many tickets should be shown per screen
• Permissions – which permissions does the agent need on a ticket so it gets shown
• Group – which group (and through Roles – which Agent) should see this Dashlet
• Default – is the Dashlet activated by default or optional for the Agent
• CacheTTLLocal – how often should the content be refreshed (in minutes)

As I stated earlier, the Dashlets are just a ticket search. If you have a look at the Attributes of the Dashlet “Reminder Tickets” – <Item Key=”Attributes”>TicketPendingTimeOlderMinutes=1;StateType=pending reminder;SortBy=PendingTime;OrderBy=Down; </Item> – you get an impression what could be possible.

The AgentTicketSearch() function is described in the Developer manual [AgentTSearch].

The Filter is one of the following values

• Locked
• Watcher
• Responsible
• MyQueues
• All

The Time can be one out of these settings

• Age
• UntilTime
  (for pending states)
• General escalation info of nearest escalation type
  • EscalationTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800”
  • EscalationTime
    (seconds total till escalation of nearest escalation time type – response, update or solution time, e. g. “3600”)
• Detail escalation info about first response, update and solution time
  • FirstResponseTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800”)
  • FirstResponseTime
    (seconds total till escalation, e. g. “3600”)
  • UpdateTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800”)
  • UpdateTime
    (seconds total till escalation, e. g. “3600”)
  • SolutionTimeWorkingTime
    (seconds of working/service time till escalation, e. g. “1800”)
  • SolutionTime
    (seconds total till escalation, e. g. “3600”)

For the initial request we just need the CustomerID, the open/new state and a permission group. Please also change the name and position of the Dashlet!

So here’s the final myConfig.xml

<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="1.0" init="Application">
 <ConfigItem Name="DashboardBackend###0600-TicketCustomerABC" Required="0" Valid="1">
  <Description Lang="en">Parameters  for the dashboard backend. ...</Description>
  <Description Lang="de">Parameter  für das Dashboard Backend. ...</Description>
  <Group>Ticket</Group>
  <SubGroup>Frontend::Agent::Dashboard</SubGroup>
  <Setting>
   <Hash>
    <Item Key="Module">Kernel::Output::HTML::DashboardTicketGeneric</Item>
    <Item Key="Title">Tickets for Customer ABC</Item>
    <Item Key="Description">All tickets for customer ABC</Item>
    <Item Key="Attributes">CustomerID=foobar.inc;StateType=open;StateType=new;</Item>
    <Item Key="Filter">All</Item>
    <Item Key="Time">Age</Item>
    <Item Key="Limit">10</Item>
    <Item Key="Permission">rw</Item>
    <Item Key="Block">ContentLarge</Item>
    <Item Key="Group">G_CustomerABC</Item>
    <Item Key="Default">1</Item>
    <Item Key="CacheTTLLocal">5</Item>
   </Hash>
  </Setting>
 </ConfigItem>
</otrs_config>

Step 4 – apply the new setting to the system

Simply run
perl bin/otrs.RebuildConfig.pl
and you have the new Dashlet definition available in your SysConfig

Ticket -> Frontend::Agent::Dashboard
DashboardBackend###0600-TicketCustomerABC

Configuration via SysConfig

and your Dashboard

Our example Dashlet

Further Reading

[AgentTSearch] – http://dev.otrs.org/2.4/Kernel/System/Ticket.html#item_ticketsearch

The post Keep an eye on certain customers appeared first on The OTRS Blog.

Last time I had a requirement of a customer, who wanted to connect OTRS with the GitHub account of his company. I think this might also be an interesting use case for you. In this small blog article you can learn, how to create an issue in GitHub via OTRS, to receive the latest information on a GitHub issue and to create comments for an issue in GitHub.

To complete this Howto, you need a running OTRS & a valid GitHub repository. Furthermore, you need a valid user login and the “access_token” of the user which should be used for the integration. The REST/JSON API of GitHub can be used by everyone, who has a GitHub account.

Use case for this connector

The GitHubConnector can be used in software developing companies, where the customer service team is using OTRS for the requests of customers and the development department is using GitHub for maintaining the source code, work on open issues a.s.o. To improve the communication (and to prevent agents to work on two different systems) you can use the GitHubConnector of this article.

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 5.0.x

OTRS Packages

You need the following Freely selectable Features of the OTRS Business Solution™ 5s :

• OTRSGenericInterfaceInvokerTicket

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

• OTRSGenericInterfaceInvokerEventFilter

(Contains additional functionalities to add conditions to events of invokers.)

Third Party Software

You need this third party software:

• XML::Simple
• XML::LibXML
• XML::LibXSLT

DynamicFields

• “GitHubIssueID” of type „TEXT“ to store the GitHub issue id (e.g.: 1)
• “GitHubCreateTime” of type “TEXT” to store the timestamp, when the issue was created
• “GitHubUpdateTime” of type “TEXT” to store the last update time of the issue in GitHub
• “GitHubIssueState” of type “TEXT” to store the latest state of the issue from GitHub

Configuring the GitHubConnector in OTRS

After you satisfied the pre-requirements, you’re ready to create a new web service within OTRS. The name of the new web service is “GitHubConnector”. Afterwards, you have to set up the needed invokers.

Configuring the Invoker “IssueCreate”

Now you’re ready to start the configuration of our Invokers. To be able to create issues in Github, you have to set up an Invoker called “IssueCreate”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing and incoming response data.

For the incoming response data, you have to select the dynamic fields (GitHubIssueID, GitHubCreateTime, GitHubLastUpdate and GitHubIssueState), which you created before.

For our XSLT mapping we need at least the following elements:

Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

You also need a XSLT-mapping for the incoming response data, because you have to store the GitHub Issue ID,  the Create Time the Last Update Time and the GitHub Issue State:

OTRS stores the GitHub Issue ID in the dynamic field “GitHubIssueID”. Afterward, it’s shown in the OTRS TicketZoom.

Furthermore, we want to know the latest State of the GitHub Issue, that’s the reason why it’s also stored in a dynamic field

The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the first Invoker.

Configuring the Invoker “IssueGet”

The next invoker is “IssueGet”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “GitHubIssueID” in the “Ticket dynamic fields” drop-down) and use “XSLT” as a mapping for your outgoing data.

As outgoing XSLT-mapping, you can use my example. I will transmit the Issue ID to GitHub because I want to get the latest Issue state.

A mapping for the incoming response data is necessary because we want to store the “LastUpdate” timestamp and the latest Issue state.

The used “Event Trigger” is the last point for this Invoker. Just select one and you’re done with the second Invoker. In my example, I’m using a dynamic field update, which is automatically set by a GenericAgent.

Configuring the Invoker “NoteCreate”

The next invoker is “NoteCreate”.  Select all the needed data for your outgoing requests (please don’t forget the dynamic field “GitHubIssueID” in the “Ticket dynamic fields” drop-down) and use “XSLT” as a mapping for your outgoing data.

Use my example as outgoing XSLT-mapping:

You don’t need a mapping for the incoming response data.

The used “Event trigger” is the last point. Select one and you’re done with the last Invoker of my tutorial. In my example I’m using an ArticleCreate event in OTRS, to trigger the Invoker.

Configuring the GitHubConnector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the Invokers because we’ve to use the right requests commands towards GitHub.Otherwise we’ll receive errors. It’s quite easy as you can see:

We don’t have to use an authentication module because we’re using the access token of a specific user in our mapping.

Afterward just click on “Save and finish”.

Testing the GitHubConnector

Testing the Requester

Create or take an already existing ticket and trigger the “IssueCreate” Invoker.

As result you should see something similar in the OTRS Debugger:

In GitHub a new issue was created:

If we now trigger the Invoker “IssueGet” we’ll see the following in the Debugger:

OTRS is now requesting everything from GitHub for a specific issue and is mapping the data into our dynamic fields:

You’ll now see the following information in the TicketZoom:

And the last the Invoker is “NoteCreate”:

You can now see that the Note was created in GitHub:

More information about the GitHub API

You can also use other resources which are provided by the GitHub API.

If you need more information, please go to the following website: https://developer.github.com/v3/

The post How to connect OTRS with GitHub appeared first on The OTRS Blog.

I think this might be an interesting use case for you if you have established a Release & Deployment management process in your OTRS system and if you want to create automatical a new host in your Icinga2 monitoring system. In this small blog article, I’ll show you, how to create a web service between OTRS and Icinga2. I’ll call this integration “Icinga2Connector”.

Like in former blog posts, there are several requirements for this HowTo:

• running OTRS 6.0.x system
• running Icinga2 system with enabled API & user credentials

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following Freely selectable Features of the OTRS Business Solution 6 :

• OTRSTicketInvoker

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

• XML::Simple
• XML::LibXML
• XML::LibXSLT

DynamicFields

The following dynamic fields should be added because they’re required for this integration.

• “Icinga2Hostname” of type “TEXT” to specify the name of the new Icinga2 host
• “Icinga2Address” of type “TEXT” to specify the login of the new user
• “Icinga2Command” of type “Dropdown” to specify the check command in Icinga2. Please use the following values:
  • hostalive: hostalive
  • http: http
  • ping4: ping4

Web service

In addition, the CMDBConnector might be useful, if you want to store the deployed item in the OTRS CMDB. You’ll find this blog article here.

Configuring the Icinga2Connector in OTRS

After you satisfied the pre-requirements, you’re ready to create a new web service within OTRS. The name of the new web service is “Icinga2Connector”. Afterward, you have to set up the needed invokers.

Configuring the Invoker “CreateHost”

Now you’re ready to start the configuration of our Invokers. To be able to create a new host in Icinga2, you have to set up an Invoker called “CreateHost”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing data.

For our XSLT mapping we need the following elements:

• the hostname, which should be displayed in Icinga2 (dynamic field “Icinga2Hostname”)
• the IP address of the new host (dynamic field “Icinga2Address”)
• the used Icinga check (dynamic field “Icinga2Command”)

Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the Invoker.

Configuring the Icinga2Connector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the invoker because we’ve to use the right requests commands towards Icinga2. Otherwise, we’ll receive errors. It’s quite easy as you can see:

As authentication module please use HTTP basic auth and fill in the user credentials of the Icinga2 API user. Afterward just click on “Save and finish”.

Testing the Icinga2Connector

Testing the Requester

Create or take an already existing ticket and trigger the “CreateHost” invoker.

As result you should see something similar in the OTRS Debugger:

In Icinga2 a new host is added:

Stay tuned…

Next time I’ll show you other useful examples how you could integrate OTRS with Icinga2.

More information about the Icinga2 API

You can also use other resources which are provided by the Icinga2 API.

Please go to the following website, if you need more information: https://www.icinga.com/docs/icinga2/latest/doc/12-icinga2-api/

The post HowTo: Connect OTRS with Icinga2 – Part 1 appeared first on The OTRS Blog.

Let’s continue with our Icinga2Connector. Last time I showed you how to create a new host in Icinga2 via API. Today I will show you how to modify hosts. To complete this how-to, you need at first a running OTRS and an Icinga2 system.

Use case for this connector

If you have a Release & Deployment management process in your OTRS system and you want to transmit information automatical to Icinga2. In this small blog article, I’ll show you, how to create a web service between OTRS and Icinga2. I’ll call this integration “Icinga2Connector”.

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following Freely selectable Features of the OTRS Business Solution 6 :

• OTRSTicketInvoker

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

• XML::Simple
• XML::LibXML
• XML::LibXSLT

DynamicFields

• “Icinga2Hostname” of type “TEXT” to specify the name of the new Icinga2 host
• “Icinga2Address” of type “TEXT” to specify the login of the new user
• “Icinga2Command” of type “Dropdown” to specify the check command in Icinga2. Please use the following values:
  • hostalive: hostalive
  • http: http
  • ping4: ping4
• “Icinga2OS” of type “Dropdown” to specify the Host OS. Use the following values:
  • Linux: Linux
  • Windows: Windows

Web service

In addition, part 1 of the Icinga2Connector might be useful. You’ll find the first blog article here.

Configuring the Invoker “UpdateHost”

Now we’re ready to start the configuration of our next Invoker. Create a new Invoker called “UpdateHost”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing data.

For our XSLT mapping we need the following elements:

• the hostname, which should be displayed in Icinga2 (dynamic field “Icinga2Hostname”)
• the IP address of the new host (dynamic field “Icinga2Address”)
• the used Icinga check (dynamic field “Icinga2Command”)
• the OS of the Host (dynamic field “Icinga2OS”)

Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the Invoker.

Configuring the Icinga2Connector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the invoker because we’ve to use the right requests commands towards Icinga2. Otherwise, we’ll receive errors. It’s quite easy as you can see:

As authentication module please use HTTP basic auth and fill in the user credentials of the Icinga2 API user. Afterward just click on “Save and finish”.

Testing the Icinga2Connector

Testing the Requester

Create or take an already existing ticket and trigger the “UpdateHost” invoker.

As result you should see something similar in the OTRS Debugger:

In Icinga2 a the host is updated:

Stay tuned…

Next time I’ll show you other useful examples how you could integrate OTRS with Icinga2.

More information about the Icinga2 API

You can also use other resources which are provided by the Icinga2 API.

Please go to the following website, if you need more information: https://www.icinga.com/docs/icinga2/latest/doc/12-icinga2-api/

The post HowTo: Connect OTRS with Icinga2 – Part 2 appeared first on The OTRS Blog.

Let’s continue with our Icinga2Connector. Last time I showed you how to create a new host in Icinga2 via API. Today I will show you how to delete hosts, if they’re retired. To complete this how-to, you need at first a running OTRS and an Icinga2 system.

Use case for this connector

If you have a Release & Deployment management process in your OTRS system and you want to transmit information automatical to Icinga2. In this small blog article, I’ll show you, how to create a web service between OTRS and Icinga2. I’ll call this integration “Icinga2Connector”.

OTRS Requirements for this HowTo

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following Feature Add-Ons :

• OTRSTicketInvoker

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

• XML::Simple
• XML::LibXML
• XML::LibXSLT

DynamicField

• “Icinga2Hostname” of type “TEXT” to specify the name of the new Icinga2 host
• “Icinga2DeleteHost” of type “Dropdown” to make a decision

Web service

In addition, part 1 & part  2 of the Icinga2Connector might be useful. You’ll find the first blog article here and the second blog article here.

Configuring the Invoker “DeleteHost”

Now we’re ready to start the configuration of our next Invoker. Create a new Invoker called “DeleteHost”.  Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing data.

Icinga2Connector DeleteHost Configuration1

For our XSLT mapping we need the following elements:

• the hostname, which should be deleted in Icinga2 (dynamic field “Icinga2Hostname”)

Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:

The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the Invoker configuration.

Configuring the Icinga2Connector “Network Transport”

Requester configuration

It’s necessary to configure the network transport for the invoker because we’ve to use the right requests commands towards Icinga2. Otherwise, we’ll receive errors. It’s quite easy as you can see:

As authentication module please use HTTP basic auth and fill in the user credentials of the Icinga2 API user. Afterward just click on “Save and finish”.

Testing the Icinga2Connector

Testing the Requester

Create or take an already existing ticket and trigger the “DeleteHost” invoker. In the Icinga2 WebGUI, the host disappears. ;-)

More information about the Icinga2 API

You can also use other resources which are provided by the Icinga2 API.

Please go to the following website, if you need more information: https://www.icinga.com/docs/icinga2/latest/doc/12-icinga2-api/

The post HowTo: Connect OTRS with Icinga2 – Part 3 appeared first on The OTRS Blog.

Many of my customers are using Rocket.Chat for their internal team chats. Last week I had a customer, who asked me if it’s possible to get a notification in their Rocket.Chat if there’s a new ticket in OTRS. I call this integration “Rocket.ChatConnector”.

The answer is… YES!

In the first part of a smaller blog article series, I’ll show you how to post messages in Rocket.Chat channels.

Like in former blog posts, there are several requirements for this HowTo:

• running OTRS 6.0.x system
• running RocketChat system

OTRS Requirements for this HowTo:

OTRS Framework

• at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-on:

• OTRSTicketInvoker

(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

• XML::Simple
• XML::LibXML
• XML::LibXSLT

Rocket.Chat Requirements for this HowTo:

• a working Rocket.Chat (I’m using RocketChat 0.64.1)

Prepare Rocket.Chat for the integration

Go to Administration -> Integration and click on “New integration” in the right upper corner and click on “Incoming WebHook”

I’ve attached the configuration of my webhook:

If you want, you can send the example JSON string to your incoming webhook with a local REST client. I’m using “Boomerang” which is an addon for Google Chrome.

The answer is a simple “success”: true

That’s all regarding the Rocket.Chat preparation. Let’s continue with OTRS.

Configuring the Rocket.ChatConnector on OTRS side

At first, we’ve to create a new web service. I’ll call it “Rocket.ChatConnector”.

Afterwards, we need a new invoker. Attached you’ll find my config:

The most important part is the XSLT mapping. The following example is tested and working:

The last part for the invoker is the used event trigger. Because I only want to inform my users if there’s a new ticket with a very high priority, I’m using the “TicketCreate” event with a condition (Priority = 5 very high):

That’s all for the invoker configuration. The next part is the configuration of the transport. I’m using a small workaround to make the integration possible. My token in Rocket.Chat is “9HHhoQYYEo2unZQrm/e4tWQgxcKkZdryfcMA325unkNrC2R6JPSmJXtuknhbQ4TYZh”.  I’ve added the first part until the “/” to my endpoint address and the second part including the “/” I’ve added to the controller mapping. Don’t forget to set “POST” as request command.

Apply all changes. Congratulations! You’re done with the first part.

Testing the Rocket.ChatConnector

Let’s test our new web service. Create a new ticket with a priority = 5 very high and see if the invoker is triggered:

The output in the OTRS debugger should look like the following:

Because of the received JSON data from Rocket.Chat, we should also see the message now in our RocketChat channel

More information about the Rocket.Chat REST API

You can also use other resources which are provided by the RocketChat REST API.

Please go to the following website, if you need more information: https://rocket.chat/docs/developer-guides/rest-api/

The post Inform Rocket.Chat users about ticket events appeared first on The OTRS Blog.