OTRS 2.2.1 Open Source Ticketing System - Not easy to tune

In one of my parallel tasks, I have been asked to help tuning an OTRS installation for a small belgian association. Although I'm generally trying to avoid getting into Perl applications, this was part of a more complete service and, having a bit of experience in Perl (from 4 years ago) I decided to go for it. Not really wanting to start a flame wars here, I think it can be said that OTRS has most of the critical flaws a bad Perl application has:

1. not well documented (code-wise) - it takes hours to actually find where the configuration file is and that it's actually partially overwritten by another configuration file. And so does it to understand how the Interface module calls the configuration file to display a page that is setup partially in each configuration file.
2. the coding style uses a lot of Perl "features" that make it practically impossible for a non-Perl developer to understand what such function is actually supposed to do
3. the resulting user interface lacks a usability touch, which makes it very impractical to use

If I were to choose a ticketing system right now, I would probably go for one of Joomla or Drupal's plugins instead. But this article is also meant to be a quick recap' of how to find your way in this mess to avoid losing the time I've lost, in the context of trying to slightly alter the global behaviour to skip the need of maually creating a login, an e-mail address and a customer ID for a client. I was once told that OTRS could be almost entirely configured from the database. I'm afraid this is completely wrong. The database allows for user preferences to be recorded, but that doesn't change global behaviour. Let's have a look at the code hierarchy. In a Debian-packaged OTRS installation, you will find the following structure:

• bin
  • cgi-bin
  • fcgi-bin
• doc
• Kernel
  • Config
  • cpan-lib
  • Language
  • Modules
  • Output
  • System
• scripts
  • auto-build
  • database
  • test
  • tools
• var
  • [misc stuff]

The bin directory is not really worth mentionning in the perspective of a quick hacking of OTRS. The Kernel/Modules directory is where most of the important classes lie. The Kernel/System is where you will have to modify behaviour once you are sure there is no way to change the configuration to get the same result. The configuration files themselves are found (strangely, as the Debian install creates an /etc/otrs directory for you) in Kernel/Config. The configuration files are loaded, in my experience, in this order:

1. otrs/Kernel/Config/Defaults.pm
2. otrs/Kernel/Config/files/ZZZAAuto.pm

I have no idea where this config load order came from, but there you go... Let's get back to our list of things to achieve... First, we want to be able to remove the necessity of an e-mail address as a mandatory field in the insertion of clients (and pretty much anywhere else). This is done by finding the CustomerUser Map in the Defaults.pm file (around line 1150). In the mapping of fields, you will find one line that looks like this:

[ 'UserEmail', 'Email', 'email', 1, 1, 'var', '', 0 ],

As commented on the first line of this Map, the 1,1, part means the field is visible *and* mandatory. Just change the second 1 for a 0 and you should be set with the e-mail address field being mandatory. That was easy. Be careful not to comment this setting out though, as this would result in the field becoming invisible for most parts of the application. Second, we want the login to be generated automatically. Just above this CustomerUser map, you will find the following lines:

# generate auto logins # AutoLoginCreation => 0, # generate auto login prefix # AutoLoginCreationPrefix => 'auto',

Make sure you change it for this:

# generate auto logins AutoLoginCreation => 1, # generate auto login prefix AutoLoginCreationPrefix => 'auto',

And you should have auto-generated logins now. Now because you know you're never going to want to actually enter this login manually, modify the map below to hide this field

[ 'UserLogin', 'Username', 'login', 0, 0, 'var', '', 0 ],

Finally, we want the customer ID to be automatically generated. This is a bit more complex. We will need to customize the code a little bit. First, add an additional setting next to AutoLoginCreation, something like:

AutoCustomerIDCreation => 1,

Then move to the Kernel/System/CustomerUser/DB.pm and find the CustomerUserAdd method (around line 300). Add a section like follows:

if (!$Param{UserCustomerID}) { if($Self->{CustomerUserMap}->{AutoCustomerIDCreation}) { my $SQL = "SELECT MAX(customer_id) FROM $Self->{CustomerTable}"; $Self->{DBObject}->Prepare(SQL => $SQL); my @Row = $Self->{DBObject}->FetchrowArray(); $Param{UserCustomerID} = sprintf("%08d",$Row[0]+1); } else { $Self->{LogObject}->Log(Priority => 'error', Message => "Need CustomerID!"); return; } }

I've let a deliberate laziness mistake here. This code will cause problems if more than one person is adding a client at the same time. There is no concurrent access prevention, which means that two employees entering a new customer at the exact same time will generate the same CustomerID. In the case above, the newly generated customer ID will look like "00000017" (always 8 digits) and will increment each new customer ID of 1. Obviously, you will need to make sure that if you have some data in your database already, it respects this new numbering. Otherwise, you're in for a big surprise while trying to find out in a lot of particularly fine ways why the customer data doesn't show in one ticket... On a side note, you might find useful to know that logging errors in the Apache log can be done through a call like this one (pretty much anywhere in a class):

$Self->{LogObject}->Log(Priority => 'error', Message => "Need UserLogin!");

Also, if you want to dump a hash, you might want to load the Data::Dumper library and then use Dump(%onehash):

use Data::Dumper; ... $Self->{LogObject}->Log(Priority => 'error', Message => Dump(%onehash));

I hope this was useful. It certainly would have been to me, but the documentation on the OTRS website seems mostly geared towards interface-administrators...