OTRS – All Services for All LDAP Customers

OTRS — Jeff Eske on June 12, 2012 at 9:13 am

In our organization, we’re using our LDAP system as our customer database.  Since we have thousands of users, it would virtually impossible to go through and make certain services available to only certain users.  The easier way for us to do it is to make all services available for all users, so that we don’t miss something.

Within the Admin interface of OTRS, you can set a group of “default services” that are available to all users.  While trying this out, I ran into a problem.  I would add a new service, go in and add it to the list of default services and try creating a new ticket.  When I would do that, I wouldn’t be able to see the new service for ALL customers.  I searched and searched online to find a solution and couldn’t find one.  I went in to the actual files and tried to find a way to always pass a particular UserID, so that it would alway use that User to determine what services to populate.  That way, I could just make sure that user was linked to the service and it would be available to everyone.

Eventually, after meeting with failure on all of those attempts, I decided to try what felt like a “hail Mary” pass.  I decided to go in and actually delete all of the records out of the service_customer_user table.  After doing that, I went in and tried creating a ticket.  Well, at that point, NO services showed up!  I went in to the Customer <>Services area in Admin and found that there were no default services chosen.  I went ahead and checked all of the services as default services and, lo and behold, they all show up for every customer now.

It appears that as soon as you start picking individual services for individual customers, it seems to interfere with the default services.  Anyway, for me, it worked to just delete all existing records and then just re-check boxes in the Admin interface.

 

OTRS – Web Services from 3.1.2 to 3.1.4+

OTRS,Web Services,Web Stuff — Jeff Eske on June 6, 2012 at 3:21 pm

UPDATE:  I’ve now created sample files and posted a quick run-through on what’s needed to use them.

When OTRS was upgraded from 3.1.2 to 3.1.4, it seemed that web services were broken.  After upgrading, my form-to-ticket processing page quit working.  I did some investigating within OTRS documentation, as well as looking at the included rpc-example.pl script to see if I could figure out what, if anything, had changed.  I went back out to their site and looked at the release notes for 3.1.4 to see if it could shed any light on the situation.  Well, in the release notes, it indicates that it fixes “Bug#8363 – SOAP Transport can’t send a value ‘0’”.   “OK then”, I say.  They did something with the web services and broke something else.  Since I knew 3.1.2 web services worked, and I needed them, I just stuck with 3.1.2.

It’s been a few weeks now and they’ve released 3.1.5 and 3.1.6 now.  I decided to download 3.1.6 and see if they “fixed” the web services problem.  Well, after upgrading my system to 3.1.6, web services STILL didn’t work!  Well, either they didn’t really care about web services, or I was missing something!

I started digging into things and found that, from what I can tell, there are now numerous other values that need to be passed in to successfully create a new ticket (not an article) via web services.  Also, as far as I can tell, the the rpc-example.pl script and the documentation haven’t been updated to indicate that.  Ive included “before” and “after” examples below.  I don’t remember for sure anymore, but I think that this blog post was my starting point for creating my original processing page.

Code that worked BEFORE 3.1.4

[CODE:]

$TicketID = $client->__soapCall(
“Dispatch”, array($username, $password,
“TicketObject”, “TicketCreate”,
“Title”,        $title,
“Queue”,        “Raw”,
“Lock”,         “Unlock”,
“PriorityID”,   1,
“State”,        “new”,
“CustomerUser”, $from,
“CustomerID”, “some ID”,
“OwnerID”,      1,
“UserID”,       1,
));

[/CODE:]

Code that works for 3.1.6 (I skipped 3.1.4 and 3.1.5, but I assume it works there also.  I’ll test to see):

[CODE:]

$TicketID = $client->__soapCall(
“Dispatch”, array($username, $password,
“TicketObject”, “TicketCreate”,
“Title”,        $title,
“TypeID”,    2,
“QueueID”,   2,
“LockID”,  1,
“PriorityID”,   2,
“State”,        “new”,
“CustomerUser”, $from,
“CustomerID”, “some ID”,
“OwnerID”,      1,
“UserID”,       1,
));

[/CODE:]

Note that I had to add TypeID, change Queue to QueueID and Lock to LockID, all with corresponding ids from the database.  Whether this is the ONLY solution or not, I don’t know, but it did get things back to where I can submit via web services again.

Jeff Eske

OTRS – Creating a Ticket Via Web Services

OTRS,Web Services,Web Stuff — Jeff Eske on June 5, 2012 at 9:53 am

UPDATE:  I’ve now created sample files and posted a quick run-through on what’s needed to use them.

The self-service page in OTRS works well for submitting tickets, but it can be made even simpler.  OTRS comes with web services capabilities that are really easy to take advantage of.  By using the web services, you can create a form with specific fields to be filled in, to help guide the customer through providing the information that you want to collect.

You could make a single-page form with all of the fields listed in one place, or you could create a “wizard” that walks the customer through a series of questions to get all of the desired information.  Once it’s all collected, you send it to a submission/processing page that associates the collected information with the appropriate field(s) within OTRS and submits it.  With my setup, I’m collecting information via several form fields, then basically combining them all and placing them in the ticket body.  I’m also determining which queue the ticket will end up in, based on the form name.  If it’s FORM1, it goes to this queue, with this priority.  If it’s FORM2, it goes to this queue, with that priority, etc.   This allows us to collect very specific information from the customer and have it sent to the correct people with no outside intervention.  It’s pretty handy.

Jeff Eske

OTRS – Changing Priority With The ITSM Module(s) Installed

OTRS — Jeff Eske on May 17, 2012 at 9:41 am

Found out something interesting today.  I was looking into configuration, regarding setting the Priority within an existing ticket.  In our case, we’re looking at using the ITSM modules, to enable a number of features that aren’t available in the base OTRS system.  The ITSM module also adds a Category<->Impact<->Priority matrix and a Criticality<->Impact<->Priority matrix.   I currently have a dev machine and a test machine both setup with the same versions of OTRS and ITSM installed.

What I noticed while comparing the two was that on one system, I was only given the option to set the Priority of an existing ticket, while on the other, I was given both Impact and Priority.  Same system setups, different options.  Why?  Well, it turns out that there is one very poorly identified option that makes the difference.

Image of the Priority page only allowing updating Priority:

Image of the Priority page allowing updating both Impact and Priority:

The option in question is located in:

SysConfig->Frontend::Agent::Ticket::ViewPriority

and is  titled:

Ticket::Frontend::AgentTicketPriority###DynamicField

Here’s an image of the option in question.

As you can see, it says absolutely nothing about what it ACTUALLY controls.  With the option checked, you’ll get both Impact and Priority.  With it unchecked, you get only Priority.

Jeff

OTRS – Web services appear to be broken in OTRS 3.1.4

OTRS,Web Services,Web Stuff — Jeff Eske on May 3, 2012 at 3:25 pm

I’ve upgraded my test machine to OTRS 3.1.4 and now my web services seem to have quit working.   They did a fix (Bug#8363 – SOAP Transport can’t send a value ‘0’. ) and now, that’s all I get!  I get no error message indicating that there’s a problem, but no ticket is created and it tells me that it created Ticket 0.  At least it can pass me that zero now…

UPDATE:  Well, it appears that the web services might not have been broken, but they changed some of what needs to be passed in to be successful – see Web services from 3.1.2 to 3.1.4+ for details.

OTRS – Completely hide “disabled” Services

OTRS — Jeff Eske on April 25, 2012 at 3:26 pm

In OTRS 3.1 and newer, evidently Services that are disabled via ACLs are now only greyed out.  For our users, it’s less confusing to make them disappear completely.  In order to accomplish this, I had to actually go into a couple of files and add some code.  See the description below.
Files Modified:
/opt/otrs/Kernel/Modules/AgentTicketEmail.pm
/opt/otrs/Kernel/Modules/AgentTicketPhone.pm

Modifications:
You need to add an else statement (the push part exists without the else part)down around:
AgentTicketEmail.pm – line 1950-1955.
AgentTicketPhone.pm – line 1875-1885.

[CODE:]
# check if service is disabled
if ( !$Service{$ServiceKey} ) {
$ServiceRegister{Disabled} = 1;
}
##### Else Brackets Added by Jeff #####
 else{
push @ServiceList, \%ServiceRegister;
}
# set service as printed
$AddedServices{$ServiceKey} = 1;

[/CODE:]

Jeff

OTRS – Show/Hide Dynamic Fields based on Service

OTRS — Jeff Eske on April 25, 2012 at 3:13 pm

PLEASE NOTE:  I’ve changed employers and have moved on to other projects.  I no longer use OTRS, or have access to OTRS, so I won’t really be able to help you beyond what I’ve already posted here. 

Jeff

With OTRS 3.1 and higher, you can create dynamic fields (formerly freetext fields) to allow collection of additional information beyond the defaults.  Normally, these fields show up in every ticket that they’ve been setup to show in.  I wanted to be able to hide the fields and then only show them when a particular Service or Services were chosen.  I’ve listed what I did below.
Files Modified:

/opt/otrs/Kernel/Output/HTML/Standard/AgentTicketEmail.dtl
/opt/otrs/Kernel/Output/HTML/Standard/AgentTicketPhone.dtl

Modifications made:

In AgentTicketPhone.dtl and AgentTicketEmail.dtl, I added some code in the section where it checks if the Service is changed:

[CODE:]
<script type=”text/javascript”>//<![CDATA[
$(‘#ServiceID’).bind(‘change’, function (Event) {
Core.AJAX.FormUpdate($(‘#NewPhoneTicket’), ‘AJAXUpdate’, ‘ServiceID’, [‘TypeID’, ‘Dest’, ‘NewUserID’, ‘NewResponsibleID’, ‘NextStateID’, ‘PriorityID’, ‘SLAID’, ‘SignKeyID’, ‘CryptKeyID’, $Data{“DynamicFieldNamesStrg”}, ‘To’, ‘Cc’, ‘Bcc’]);

############  Added by Jeff ##############
#Core.Agent.InitFocus();
switch ($(‘#ServiceID’).val() ) {
case  “2”:
document.getElementById(‘id name’).style.display = ‘block’;
break;
case  “3”:
document.getElementById(‘id name’).style.display = ‘block’;
break;
default:
document.getElementById(‘id name’).style.display = ‘none’;
}

#########  End – Added by Jeff ###########
});
//]]></script>
[/CODE:]

Then I added the “id name” to the Dynamic Field that I wanted to Show/Hide:

[CODE:]
<!– dtl:block:DynamicField_FieldName –>
<div id=”id name” style=”display:none;” class=”Row Row_DynamicField_$QData{“Name”}”>
$Data{“Label”}
<div>
$Data{“Field”}
</div>
<div></div>
</div>
<!– dtl:block:DynamicField_FieldName –>
[/CODE:]

Now, by default, the dynamic field is hidden. When you choose a Service with the ServiceID or 2 or 3, it automagically appears!

Jeff Eske

OTRS – Adding Templates to OTRS

OTRS — Jeff Eske on February 6, 2012 at 3:51 pm

We’re currently investigating using OTRS, with the ITSM modules, as a possible ticketing system.  In version 3.0, they’ve got the ability to add ticket templates.  Templates are nice in that they allow you to create semi-complete tickets just by choosing a template.  That is one of the features that FrontRange’s ITSM product have in Version 7 that we were really looking forward to having.  Currently, in FRS’s ITSM (version 6) we’re using QuickActions to do basically the same thing.

There is a great Youtube video that describes what to do to get templates working in the default form.   The problem is that the example template code that OTRS has in the AgentTicketPhone.dtl file discussed uses a button to choose the template text.  That’s all well and fine for some browsers, but doesn’t work in all of them, due to using the onclick function.  Seems that Safari and some other browsers just ignore that. Plus, in my opinion, it would be pretty ugly, and reminiscent of a 1990’s webpage, to have a dozen different buttons to click on.  Maybe if they were each a different color and blinked…

Anyway, after some Trial and Error, I was able to get a cleaner method working – in IE, Firefox, Safari, and other browsers.  I replaced the button(s) with a dropdown menu.  This is simply a select tag, with an option representing each template form.  It then uses the onchange function, rather than the onclick function, fire off the appropriate form.  This means that all of the major browsers seem to be all right with it.  I tested it in IE, Firefox, Opera, Safari, and Chrome and they all worked as expected.

What I’ve done is create a custom theme, then copied and altered the AgentTicketPhone.dtl file to add my changes.  This means that during upgrades, my changes won’t be overwritten, since they’re not made in the default file.

Anyway, the way the example is written in the file is:

As you can see, it uses the onclick function and each template would require its own button.

What I’ve done, is add a dropdown via the select tag and its options and used the onchange function:

Things to note are:

1> Make sure to add the id=”some_name” to your select tag, or the GetElementByID() won’t work, since there won’t be an ID to get.

2> The option values are actually the names of each form that I’ve added at the bottom of the page.  That means that there’s a form at the bottom with id=”PassReset” and one with id=”VirusMalware”.   These forms contain the fields and values that you want to use to automagically populate the ticket.  Changing the fields and values is covered in the video.

 

Installing/Configuring the OTRS Ticketing System

OTRS — Jeff Eske on January 24, 2012 at 2:59 pm

I’ve been tasked with installing/configuring the open-source version of the OTRS ticketing system, with the ITSM modules, for evaluation here at work.  So far, I’m really happy with it.  I have the basics setup and ready to go and I must say that it seems easier to configure than FrontRange’s ITSM.  Another nice thing – IT’S FREE!  From my experimentation, it appears that since it’s completely web-based, it works on virtually any device with a browser and network access.  On top of that, there’s an iPhone app available too.  FRS’s ITSM product is .Net-based.   That means that it doesn’t really work with non-Windows devices.  ITSM Version 6 had a fairly robust web client available that could be used by the Mac people.  ITSM Version 7, on the other hand, drops that web client.  That means that Mac users are basically SOL, unless they use the free iPhone app.  “Ah”, you say,  “that’s simple enough.  Just download it and go!”.  Well, if only it was that easy.  To use the mobile client, you have to purchase the Mobile server module(s) – and the licenses to go with it.

OTRS Pros so far:
IT’S FREE!
Initial install was straightforward.
A lot of configuration options.
Very flexible, due to the above.
Good support in the forums.
Totally web-based, so it works with virtually any browser.
Has an iPhone app available.

OTRS Cons so far:
A lot of configuration options = A LOT of configuration options.
Looks slightly “clunky” compared to FRS’s ITSM.  A certain amount of that can probably be corrected fairly easily – somewhere within the configuration options.
No tech support number to call – without paying for support.
No true Workflow engine to assist with ticket routing, etc.

We’ll see what else comes up as I move forward.

 

« Previous Page
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. | Jeff's Blog