OTRS – Manuallly Importing CMDB Items

OTRS — Jeff Eske on June 19, 2013 at 7:56 am

UPDATED:  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

I’ve seen the number of people looking at my short entry dealing with importing items into OTRS’s CMDB, so I thought I’d expand on that a bit.  I’ll go ahead and give a slight overview, then provide a quick-and-dirty description of how to manually import items into the CMDB.  Later, when time permits, I’ll add a better explanation of how to automate the import process.  I may clean this up at a later time, bur for now, I want to get down the basics.

You can manually import CMDB items (computers, software, etc.) into OTRS using the Import/Export function, via the web interface.  There is also a way that you can automatically import items, via cron and the commandline.  I have a brief overview of that here, but will create a more complete explanation at a later time.  First things first though; you have to do the steps below anyway, before you can automatically import items.  You have to have the import template created in order to automate the process, since the automation uses an existing template.

Overview

To create the template, we’ll need to identify what we’re importing, the delimiter, and the CMDB columns to be included.  In my example, I’m importing desktop computers, the file is a comma-delimited format, and I’ll be submitting the minimum required fields.

Required Fields
What I mean by minimum required fields is that OTRS has a small number of fields within a CMDB record that have to be filled in.  If you go into the CMDB section online and manually add an item, you can see what the requried fields are; they’ll be marked with an asterisk (star).  For my desktop computer import, I’ll need to AT LEAST provide: Computer Name,  Deployment State, Incident State, Network Adapter  1(NIC1), and whether it gets IP over DHCP.

Creating an Import Template

So, here’s a quick-and-dirty rundown of how to setup an import template.  The values that are shown in the images below SHOULD get you a working template.  You will however, probably want to edit the values to more precisely match what you need.  As always, please read my disclaimer before proceeding.

1> Goto: Admin -> System Administration -> Import/Export

Import/Export Link Location

 

2> On the Import/Export Management screen, click the “Add Template” button.

Import Template - Add Template

 

3> Set the values in the Step 1 screen

Import Template - Step 1

Name: Name of your new template
Object: The object type
Format: format of the import data
Valid: set it as valid, if you want to be able to use the template…

 

4> When finished, click Next

 

5> Set the values in the Step 2 screen

Import Template - Step 2
Class: whatever type of import it will be – this affects what elements show up later.
Maximum number of one element: Not sure what this does 🙂
Empty field means keep value:  This will leave existing data, rather than “blanking” it out.

6> When finished, click Next

 

7> Set the values in Step 3 screen

Import Template - Step 3
Column Separator: The separator used in your import file.
Include Column Headers: That’s up to you.  I do “No”

 

8> When finishd, click Next

 

9> Add mapping elements

Import Template - Step4

There are a few things to note when adding elements:

1> Click “Add Mapping Element” to add a line for each field that is in the import file.
2> Add an entry for EVERY field in the import file, in the order they exist in the file.
3> There are some REQUIRED fields.  These fields have to exist in the import file, and have valid values, in order for the record to import.  The required fields are: Name,Deployment State, Incident State,NIC1,IP over DHCP
Name,Vendor,Model,OS,NIC-IP

 

10> When finished adding elements, click Next

 

11> Fill in search criteria to be used for exporting (optional)

Import Template - Step 5

You don’t really need to do anything with this, if you’re only planning on importing items.

12> If/when you finish adding search criteria, click Finish

 

13> Note the number of the template that you just created

List of Existing Templates

This should bring you back to Import/Export Management page that shows a listing of the existing Import/Export templates.  You should see your newly created template listed there.  Note the Number of your template, since this is what will be used to automate the import.

To actually import items, you’ll simply click on the “Import” link for the appropriate import template, select the source file with all of the records in it, and hit the “Import” button.  When it finishes, it will give you Summary page which indicates total records, successes, and failures.

 

 

OTRS – Parsing Out the Variables in a SOAP Response

OTRS,Programming,Snippets,Web Services,Web Stuff — Jeff Eske on March 5, 2013 at 5:16 pm

Unlike some web services, the OTRS web services don’t return the values in specific xml tags; it uses generic “s-gensym” tags.  Also, it returns field name within a set of generic tags, followed by the field value in a set of generic tags.  Here’s part of the SOAP response:

<s-gensym1558 xsi:type="xsd:string">PriorityID</s-gensym1558>
<s-gensym1560 xsi:type="xsd:int">3</s-gensym1560>
<s-gensym1562 xsi:type="xsd:string">ServiceID</s-gensym1562>
<s-gensym1564 xsi:type="xsd:string" />
<s-gensym1566 xsi:type="xsd:string">Type</s-gensym1566>
<s-gensym1568 xsi:type="xsd:string">Failure</s-gensym1568>

Makes a lot of sense, doesn’t it?  Here’s an example of one that actually uses the field name as the enclosing tag name.  It makes it easier to understand:

<fusion:ServiceDown><fusion:v>false</fusion:v></fusion:ServiceDown>
<fusion:BusinessUnit><fusion:v>Some Business Unit</fusion:v></fusion:BusinessUnit>

In this example, you can see that the ServiceDown field(fusion:ServiceDown) has a value(fusion:v) of “false”.  With OTRS, every time you run your SOAP request, you some random-ass “s-gensym” field name for everything.

To actually pull the SOAP response data out, you can use a foreach() loop and dump the field names and values into a more useful array.  In addition to that, the array will be setup as a key/value pair, so you can actually get the field value by referring to the field name.  I’m sure that there’s a much better, more elegant method to do the same thing, but this way works.  First the code, then an explanation of what’s going on:

[code]
$ticketInfo = array();
$i = 0;
foreach ($TicketDetails as $name => $value){ 
 if (false !== strpos($name, "s-gensym")){
 $temp[$i] = $value; 
 $v = $temp[$i-1]; 
 if($i % 2 != 0){ 
 $ticketInfo[$v] = $value; 
 }
 $i++;
 }
}
[/code]

Basically, what this code does is take your SOAP response array ($ticketInfo) and run it through a foreach() loop.  The OTRS SOAP response includes to entries for each field.  The first entry is the field name and the second entry is the field value.  So, what I want to do is combine both entries into a key->value pair in an array.

The foreach() explodes the values of the s-gensym variables out and adds the value to 2 different arrays.  This is where the elegance is definitely lacking.  I’m first saving the value into the $temp[] array to refer back to it later.  Then, if the row is divisble by two – basically every other, or every second row, I grab the previous value from temp[] and write it to $ticketInfo[] as the key and write the current value as the value.  What I end up with in the end is an array ($ticketInfo[]) that has the field name as the key and the field value as the value.

You can then pull the desired value by referring to the appropriate key, such as:

$ticket_age = $ticketInfo[Age];
$ticket_title = $ticketInfo[Title];

A simple way to print out all of the values in your array is, again, with the foreach() loop.  All you need is this little piece of code:

[code]
foreach ($ticketInfo as $name => $value){
 echo "<b>".$name.":</b> ".$value."<br>";
}
[/code]

The foreach() will loop through the array and explode out the key/value pairs, then echo them out.  It can be handy for troubleshooting, to see what everything actually looks like in the array.

Jeff Eske

OTRS – Web Services Descriptions and Examples

OTRS,Web Services,Web Stuff — Jeff Eske on March 5, 2013 at 4:47 pm

The OTRS ticketing system comes with some basic web service functions included by default.  I’ve already done a post about using web services to create a new ticket via TicketCreate(), as well as a post about retrieving an existing ticket via TicketGet().  I’ve also created a page to allow you to search for a ticket using the TicketSearch() function, but I haven’t posted anything about that yet.  I’ve also posted a code snippet that actually helped me considerably when I was troubleshooting exactly what was going on.

What I’d like to do here is just note some observations that I’ve made while messing around trying to figure all of this out.  Hopefully it will be of some use to someone.  As with everything on this site, the Disclaimer holds here to – all I can guarantee is that this stuff worked for me.  What I have listed below is what I’ve determined from trial-and-error, so take it with a grain of salt.  This is almost more to document it for myself than anyone else.

===============

TicketCreate()
Purpose:
Used to create new tickets object (duh!).  Generally, you’ll want to do an ArticleCreate() also, to add some useful information to the ticket.
Required Input Values: TypeID(integer), QueueID(integer), LockID(integer), PriorityID(integer), State(text), CustomerUser(text), OwnerID(integer), UserID(integer).
Optional, but Recommended: Title(text). The title is required, but it seems logical to add one.
Returns: TicketID(integer)

[code]
// PHP code sample for TicketCreate().  Adjust the values as necessary
$TicketID = $client->__soapCall(
 "Dispatch",array($username, $password,
 "TicketObject", "TicketCreate",
 "Title", "Some Title",
 "TypeID", some_typeID_number,
 "QueueID",  some_queueID_number,
 "LockID", 1,
 "PriorityID", some_priorityID_number,
 "State", "new",
 "CustomerUser", "some_user@your_organization",
 "OwnerID", some_ownerID_number,
 "UserID", some_userID_number,
 )
 );
[/code]

===============

ArticleCreate()
Purpose: Add an article to a ticket.  The TicketCreate() function basically just creates a “wrapper” for articles.  The articles provide the content.
Required Input Values: TicketID(integer), ArticleType(text), SenderType(text), HistoryType(text), HistoryComment(text), ContentType(text), UserID(integer)
Optional, but Recommended: From(text), Subject(text), Body(text), Loop(integer), AutoRepsonseType(text), OrigHeader(array)
Returns: ArticleID(integer)

[code]
// PHP code sample for ArticleCreate().  Adjust the values as necessary
$ArticleID = $client->__soapCall("Dispatch", 
array($username, $password,
"TicketObject", "ArticleCreate",
"TicketID", some_ticketID_to_add_article_to,
"ArticleType", "webrequest",
"SenderType", "customer",
"HistoryType", "WebRequestCustomer",
"HistoryComment", "created from PHP",
"From", "some_customer@your_organization",
"Subject", "Some Subject",
"ContentType", "text/plain; charset=ISO-8859-1",
"Body", "Some Article Body text",
"UserID", some_userID_number,
"Loop", 0,
"AutoResponseType", 'auto reply',
"OrigHeader", array(
'From' => 'some_customer@your_organization',
'To' =>  'some_customer@your_organization',
'Subject' => 'Some Subject.  Probably the subject from above',
'Body' => 'Some Body text.  Probably the body from above'
),
)
);
[/code]

===============

TicketGet() 
Required Input Values: TicketID(integer)
Returns: Array of Age(integer), PriorityID(integer)ServiceID(integer), Type(text), Responsible(text), StateID(integer), ResponsibleID(integer), ChangeBy(integer), EscalationTime(integer), Changed(date/time), OwnerID(integer), RealTillTimeNotUsed(integer), GroupID(integer), Owner(text), CustomerID(text), TypeID(integer), Created(date/time), Priority(text), UntilTime(integer), EscalationUpdateTime(integer), QueueID(integer), Queue(text), State(text), Title(text), FirstLock(date/time), CreateBy(integer), TicketID(integer), StateType(text), EscalationResponseTime(integer), UnlockTimeout(integer), EscalationSolutionTime(integer), LockID(integer), TicketNumber(integer), ArchiveFlag(text), CreateTimeUnix(unixtime), Lock(text), SLAID(integer), CustomerUserID(text)

[code]
// PHP code sample for TicketGet().  Adjust the values as necessary
$TicketDetails = $client->__soapCall("Dispatch", 
array($username, $password,
"TicketObject", "TicketGet",
"TicketID", some_ticketID_number,
"Extended", 1,
));
[/code]

===============

TicketSearch()
Required Input Values: CustomerUserID(text)
Returns: Array of TicketID(integer), TicketNumber(integer)

[code]
// PHP code sample for TicketSearch().  Adjust the values as necessary
$TicketDetails = $client->__soapCall("Dispatch", 
array($username, $password,
"TicketObject", "TicketSearch",
"CustomerUserID", "some_customers_login",
));
[/code]

One additional thing to note.  Both of the last two functions return arrays of values, rather than a single value.  You might want to look at my post about how to parse the values into a usable array.

Jeff Eske

SEE ALSO:
OTRS – Simple Web Service Example Using PHP,

PHP Script to Display SOAP Requests and Responses,

OTRS – TicketGet() Web Service Example in PHP

OTRS – TicketGet() Web Service Example in PHP

OTRS,Web Services,Web Stuff — Jeff Eske on March 5, 2013 at 11:42 am

UPDATED:  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

Continuing on with my studies of OTRS web services, I’ve created a page that will pull an OTRS ticket back when supplied with the ticket’s ID via GET.  Prior to this I posted how to create a ticket using the OTRS TicketCreate() SOAP function. Basically, you give the page the ticket ID via the URL – http://webserver/get_ticket.php?id=xx. I’ve included a complete ticketGet zip file at the end.  In addition to this example, I have another post explaining how to submit a ticket via web services.

Basically, all that’s required is passing one argument, the TicketID, and you can get back ALL of the ticket details.  It’s actually much more straightforward than I assumed that it would be.  One thing that I noticed is that reading through the OTRS dev documentation, the order that the ticket details are returned is different than what actually comes back.  That’s not really a big deal, since I moved everything into an array, with the various ticket details saved as a key/value pair.  More on that later.  The example that I have here only returns the ticket, but it is possible to return the associated articles also, but that will be for a later post.

The actual soapCall() function looks like this:

[code]
$TicketDetails = $client->__soapCall("Dispatch", 
array($username, $password,
"TicketObject", "TicketGet",
"TicketID", $TicketID,
));
[/code]

All I’m passing in is the SOAP username and password, along with the TicketID.  What it returns then is an XML-formatted response.  My page parses all of the returned values into an array, by using a foreach loop.  There are probably much more elegant solutions, but this works. Because of the way OTRS returns things, my foreach loop is a little janky.  Like I said, there’s probably a more elegant solution.

Without further ado, here’s the foreach loop:

[code]

$ticketInfo = array();
$i = 0;
foreach ($TicketDetails as $name => $value){
    if (false !== strpos($name, "s-gensym")){
        $temp[$i] = $value;
        $v = $temp[$i-1];
        //echo $value."<br>";
        if($i % 2 != 0){
            $ticketInfo[$v] = $value;
        }
        $i++;
    }
}
[/code]

As I said – a little janky.  Anyway, basically what OTRS does it returns the detail’s name as a variable, then the detail’s value as the NEXT variable like: “Age”, “123421”, “Title”, “This is my ticket title”, “TicketID”, “2”, so basically, you get the detail name, then the detail value.  To get these into a usable format, I’m basically creating 2 arrays, $temp[] and $ticketinfo[].  Since I’m simple-minded, the easiest thing for me to do was to create the $temp[] array so that I could basically use it as the “key” array when populating the $ticketinfo[] array.  Then what I’m doing is basically putting things into the $ticketinfo[] array as key/value pairs.  I take the current value – $value and put it in as the value and use the previously returned value, from $temp[], as the key.

I’ve included the complete commented code for the page below.  You can copy/paste it into a new, blank page, or you can download the zipped version of the file below.

[code]
<?PHP
error_reporting(E_ALL);
#### OTRS specific information ####
$url = "http://your_otrs_server/otrs/rpc.pl"; // URL for OTRS server
$username = "SOAP_username"; // SOAP username set in sysconfig
$password = "SOAP_password"; // SOAP password set in sysconfig
$TicketID = $_GET[id];
########################################################################
#### You don't have to change anything below here, although you can ####
########################################################################
#### Initialize new client session ####
$client = new SoapClient(
 null, 
 array(
 'location' => $url,
 'uri' => "Core",
 'trace' => 1,
 'login' => $username,
 'password' => $password,
 'style' => SOAP_RPC,
 'use' => SOAP_ENCODED
 )
);
#### Create and send the SOAP Function Call ####
$TicketDetails = $client->__soapCall("Dispatch", 
array($username, $password,
"TicketObject", "TicketGet",
"TicketID", $TicketID,
));
#### Get the SOAP response into an array as key/value pairs ####
# This is kind of janky, but what it does is parse out the #
# detail values in the SOAP response and writes them as a key/value #
# pair in the $ticketInfo[] array. #
$ticketInfo = array();
$i = 0;
foreach ($TicketDetails as $name => $value){ // explode the xml response
 if (false !== strpos($name, "s-gensym")){
 $temp[$i] = $value; 
 $v = $temp[$i-1]; 
 if($i % 2 != 0){ 
 $ticketInfo[$v] = $value; 
 }
 $i++;
 }
}
##############################################################################
#### The code below here is just to provide viewable proof that it worked ####
#### It can all be commented out or removed ####
##############################################################################
#### Return the SOAP request and response as xml-formatted text ####
print "<pre>\n"; 
print "Request :\n".htmlspecialchars($client->__getLastRequest()) ."\n"; 
print "Response:\n".htmlspecialchars($client->__getLastResponse())."\n"; 
print "</pre>";
echo"<hr width='200'>";
// Spew out the key/value pairs from the $ticketInfo[] array
foreach ($ticketInfo as $name => $value){
 echo "<b>".$name.":</b> ".$value."<br>";
}
?>
[/code]

Here’s the ticketGet zip file.  The formatting is obviously better in that version than what you see above.

Jeff Eske

 

OTRS – Mobile Front-end

OTRS,Programming,Web Stuff — Jeff Eske on February 19, 2013 at 1:30 pm

I’m in the process of creating a mobile front-end for OTRS.  There are a couple of decent apps out there that can be used on iOS and Android, but I decided to create a completely HTML-based version, just because I can.  I’ll post a video of the progress so far.

Stay tuned.

UPDATE: I have a link to a short video that shows it in action below.  Click on the image to view the video.

In the video, I’m accessing the mobile pages on my old Motorola Droid X.  I’ve tested it on the Droid, as well as an iPhone 4S (being used to take the video) and an iPad.  Since it’s really basic HTML, it works great on all of them.

 

OTRS Mobile front-end walkthrough

OTRS Mobile front-end walkthrough

It’s still very much a work-in-progress.  Currently, it’s “read-only”.  I’m in the process of adding two-way functionality, utilizing OTRS web services.

Jeff Eske

OTRS – “EOF – End of data in parsing input stream” Error When Importing to CMDB

OTRS — Jeff Eske on October 2, 2012 at 2:30 pm

I’ve started into the process of automatically importing a data dump of CI information from LANDesk.  In the near future,  I’ll create a step-by-step tutorial on how to set all of that up, but for now I want to address the “EOF – End of data in parsing input stream” error.  It appears that the error is related to how the Text::CSV_XS perl module handles reading data from at least SOME text files.  That module isn’t necessary for the .csv importing to work; it evidently just speeds up processing.  I solved the issue by simply deleting the Text::CSV_XS module.

What turned me on to that as the possible culprit was a post that I found somewhere on the Internets that indicated that Text::CSV_XS can have problems seeing the end of files.  There’s also a note on the TEXT::CSV_XS cpan page (http://search.cpan.org/~hmbrand/Text-CSV_XS-0.91/CSV_XS.pm) that indicates that there can be a problem.  I’ve also seen indications that it may be related to file encoding also, so I’ll test that and see.

UPDATE:  I re-installed Text::CSV_XS and tried various different document encodings with the same “EOF” error.

Jeff Eske

 

 

OTRS – Import Configuration Items From Outside Sources

OTRS — Jeff Eske on August 28, 2012 at 11:29 am

OTRS’s web services only work for tickets and articles.  At the present time, you can’t really manipulate other items within OTRS via web services.  One of the things that we’d like to be able to do though is to leverage our LANDesk information within OTRS.  We would like to be able to automatically create CI records within OTRS and populate them with LANDesk data from our users’ PCs.

I’ve been experimenting with a way to get our LANDesk information into OTRS.  The method that I’ve come up with isn’t ideal by any means, but it seems to work.  OTRS has an import/export utility that can actually be used to bring in outside information.  First, you need to create a template from within the OTRS Admin interface.  Once that’s done, you can then setup a cron job to actually run the import/export script, utilizing the template that you created.  You’ll also need to create a directory where a LANDesk data dump can land.

The basic process would be:

1> LANDesk runs a search for Items and creates a delimited text file of the items.  Once an initial run of ALL Items is done, this should probably just be for any Items that have changed since the last run.

2> The LANDesk data dump file is dropped to a directory that’s accessible to both LANDesk and OTRS.

3> The OTRS import/export script is run and imports the LANDesk CI information into OTRS.  It creates new Items, or updates existing Items

4> Rinse and repeat.

Our environment is static enough that we probably won’t run the whole process more than once or twice a day, but it could be done more often.  In a future post, I might walk through the whole process of creating the template, etc.

UPDATE – 10/3/12:  I ran into an end-of-file (EOF) error when running the import script. I’ve noted what I did about it here.

UPDATE – 6/19/13: I’ve added an entry describing how to create the necessary import template.  You can read that here.

Jeff Eske

OTRS – Simple Web Service Example Using PHP

OTRS,Web Services,Web Stuff — Jeff Eske on July 27, 2012 at 10:54 am

UPDATED:  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

A fair amount of my traffic seems to be people looking for information about using web services in OTRS.  I’ve written a couple of entries about this in the past.  One covers changes in the services from 3.1.2 to 3.1.4.  In the other entry, I briefly described how easy it is to create tickets via web services.  This time around, I’ll provide a basic example of how to actually create a ticket via web services, using PHP to make the TicketCreate() SOAP request.  I’m in the process of integrating this into a mobile front-end for OTRS.

UPDATE: 2013-2-25 – I’ve just tested this with version 3.2.1 and it still works, as is.

UPDATE: 2013-3-5 – I’ve added a post describing how to use the OTRS TicketGet() SOAP function also.

I’ve created a zip file that contains two files.

form.html
form.html is a VERY basic html page that has a form on it.  There are only 3 fields in the form – Customer Login ID, Title, Description.  You could very easily add, or even remove, fields in the form to allow more, or less, control by the end user.

add_ticket.php
add_ticket.php actually does the heavy lifting.  There’s a section towards the top where you’ll need to set some variables to match your implementation of OTRS.  I’ve commented the code, but I’ll go over the variable part below.

Here’s the section of add_ticket.php that will need to be updated to your specifics:

[CODE]

#######    PLEASE SET THESE VARIABLES TO MATCH YOUR SYSTEM     #########
#  You can set others in the code below, but these should be the main  #
#  things that you may want to adjust.                                 #
########################################################################

$url      = “http://your_otrs_server/otrs/rpc.pl”;  // URL for OTRS server
$username = “SOAPusername”;  // SOAP username set in sysconfig
$password = “SOAPpassword”;  // SOAP password set in sysconfig
$typeID = 2; // id from ticket_type table
$queueID = 2; // id from queue table
$priorityID = 1; // id from ticket_priority table
$ownerID = 2; // id from users table

[/CODE]

The first 3 – $url, $username, $password, are all pretty simple.  As the comment in the example above notes, and as Tomasz pointed out in his comment, you will need to set the SOAP username and password in the OTRS Admin interface at –

http://server/otrs/index.pl?Action=AdminSysConfig;Subaction=Edit;SysConfigSubGroup=Core::SOAP;SysConfigGroup=Framework;#

One thing to remember on the URL is that if you are using SSL on your server, you’ll need to change from http:// to https://.  The other 4 – $typeID, $queueID, $priorityID, and $ownerID,  will all need to be changed to ids from your system.

I use MySQL Query Browser to pull back this info but, due to the way OTRS works, you can gather that info directly from the application.  For instance, to find the id for the user that you want to use as the default owner, you can simply go in as an Admin and goto Admin > Agents.  Once you have the list of Agents, simply mouse over the Agent that you’d like to use.  When you mouse over, you should see the URL in the Status Bar of the browser.  If you look at the URL – https://otrs_server/otrs/index.pl?Action=AdminUser;Subaction=Change;UserID=2;Search=, you’ll see UserID=some number (bolded in the example).  This number is the id that you need.  Same with the other values.  You should be able to find places within OTRS with links to the things that you need.  Within the URLS, there will be an id=number.  That number should be the value that you need.

If you understand PHP, forms, and form processing, it’s really easy to expand the usefulness of forms.  Some examples would be:

1> Add form fields to collect specific information from the customer that is necessary for solving the problem but isn’t readily available otherwise.  You then take those bits and pieces and combine them into the description, via the add_ticket page.  This can get you a more complete description of the problem than possible with a simple text box where the customer is responsible for trying to figure out what needs to be added.

2> Add a Type dropdown to the form and pass that id over to add_ticket.  That would allow the customer to indicate if it was a failure, request, etc.

3> Add a Priority dropdown to the form and pass the id.  That would allow the customer to indicate what they think the priority is.  In my experience, most will mark it as High Priority, no matter how mundane the issue…

Generally, in my experience, the less choices that you give to the customer, the better off you are.

Anyway, have fun.

Jeff Eske

================================
Download the zip file – Simple Web Services example

OTRS – Remove “Company Tickets” from Customer Portal

OTRS — Jeff Eske on June 21, 2012 at 2:27 pm

I’m not totally sure what a person is supposed to do with the “company” options within OTRS.  The way our organization is setup, I don’t see any real use for it.  In fact, in our situation, it probably wouldn’t do anything but confuse our end users.  To help eliminate that possibility, as well as to simply help simplify the interface, I wanted to remove the “Company Tickets” link from the customer interface.

After a little searching on the internet and a little poking around in OTRS, I found what I needed to do. I needed to remove an entry from Ticket -> Frontend::Customer::ModuleRegistration

1> Login to OTRS and go to Admin > SysConfig.

2> Use the Actions dropdown and choose “Ticket”.
Choose Ticket from Dropdown

3> Once the list of Ticket-related settings come up, scroll down and click on “Frontend::Customer::ModuleRegistration”.

Frontend::Customer::ModuleRegistration

4> Once you’re in the ModuleRegistration settings, scroll down until you find one called “Company Tickets”.

Company Ticket entry

5> Click on the little “minus” at the bottom of the entry, to delete it.

6> Once the page refreshes, scroll to the bottom and click on “Update” to finalize everything.

7> Log in to the Customer portal and verify that “Company Tickets” no longer shows.

Jeff

 

OTRS – Moving dynamic fields around in the New Ticket View

OTRS — Jeff Eske on June 15, 2012 at 10:53 am

UPDATED:  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

By default, OTRS places the dynamic fields at the bottom of the ticket and basically uses a function to scroll through and list them, one right after the other.  One nice feature that can be taken advantage of though, is the ability to hardcode the display of specific dynamic fields.  Using this, in addition to setting things up to show/hide the dynamic fields in different situations, allows us to setup the new ticket page in a more customizable manner.  You can actually put the code that displays the dynamic field anywhere within the ticket page that you want to, which means that you can move it from the bottom of the page up closer to the top, so that it’s more prominent.

One thing to remember though – if you leave the default dynamic field function in at the bottom of the page, the dynamic field will still be displayed there also.  What I did was comment out the default function and just hardcode in my dynamic fields where I wanted them.  The downside is that any new dynamic fields that are added to OTRS won’t automatically display.  You’ll have to go in and manually add them to the New Ticket page.  The upside is that you can position the field exactly where you want it on the page.

Jeff

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