Hi Everyone,
First, thanks Jesse for soliciting input from the user community;
hopefully this input will improve the quality of the software. Second,
this message is not meant to be critical, as its goal to get the user
community more involved in the Request Tracker development process.
As I reviewed the responses to this thread the one constant I saw and
kept coming to mind was better technical documentation. A fair amount of
the ideas submitted could have been easily accomplished by writing an
extension to RT or a standalone script in perl. This is easier said than
done. I have written several reporting scripts and added a few code
modifications to Request Tracker to add functionality to the code. I
will say writing the code to do this was not very easy.
All I had to go on was looking at existing Request Tracker code, and
through trial and error, I was able to code what I wanted to do.
Sometimes the code to get certain data items amounted to less than 10
lines of code. But, to derive the 10 lines of code could take hours. I
also submitted questions to this forum and there were folks who were
very helpful when I truly got stuck.
What is sorely needed for Request Tracker is a true and serious
technical documentation manual. A manual that really explains all the
functions and calls used specifically in Request Tracker (libraries,
etc.), including example code. To the uninitiated looked through Request
Tracker code to figure out how to read ticket information, generate
reports, etc. is not a very pleasant experience. Fortunately, I was able
to use code from various contributed software extensions to construct
reports and Request Tracker extensions by extrapolating how something
was done and applied it to what I wanted to do.
I am surprised that there are not more contributions to the Request
Tracker archive; considering the number of sites which use Request
Tracker. Part of this reason is what is embodied in this message. A
good, solid technical manual would go a long way to improve Request
Tracker because more people will be able to understand how to construct
viable code.
In regards to handling mandatory fields, we came up with a compromise
solution. We only have folks who manage tickets the capability to log
into Request Tracker. We created a set of external CGI scripts which
capture the ticket data needed to populate a ticket. All field checking
is done within the CGI. Also, we are free to set up field widths any
size we like and format the CGI form in a more user friendly manner.
Once the user submits the ticket, the ticket is e-mailed directly into
Request Tracker through the ExtarctCustomFieldValues template (available
at the Wiki). We just make sure that the various field values are in the
body of the e-mail can be detectable by the ExtarctCustomFieldValues
template. Finally, we set up an unprivileged account called “guest”,
which allows the user to view their new ticket via e-mail and via the
CGI script after they submit the ticket. We modified all the other
e-mail specific templates to include the “guest” account user name and
password in the URL. So far, we have had no issues with tickets not
being filled in properly; which has made many folks lives easier.
Finally, by using a CGI scripts and e-mail there is not direct
interaction with Request Tracker and the database.
As for reporting, I created several scripts which provide metrics on our
queues. These scripts can produced both text based and spreadsheet (perl
model request) for management and higher up review. These scripts used
some of the programming ideas in RTX::Statistics and rt-remind.pl, both
are available on the Wiki. Some additional programming had to come by
looking at Request Tracker code itself.
In regards to Asset Tracking and change control, we use Asset Tracker
and have a field called “Change Comments”. When a person makes a change
on the asset, they put something into “Change Comments” which the value
is placed in the Asset history. While this is not very elegant it gets
the job done. In addition, I created a set of scripts which uses SSH
tunnels to obtain configuration information from our UNIX/Linux based
systems. The data is then filtered and a report is created for each
host. Another script parses the reports and updates various custom
fields for the appropriate asset maintained in Asset Tracker. This works
99.99% of the time; however, sometimes SSH will hang on systems which
ran out of disk space. We run this script against 300 systems each
night, barring SSH hangs, takes about 20 minutes to complete. With the
exception of updating custom fields in Asset Tracker, virtually all the
code does not require knowledge of the internals of Request Tracker or
Asset Tracker. As for the custom field updates, well this required
bothering the author of Asset Tracker a lot and reading through the
code.
Finally, the conclusion one should reach from this message that if there
was a solid technical documentation manual, much of what is being
requested could have been developed by the user community. What is
contained herein are some of my experiences over the past 18 months;
beyond that time I never heard of Request Tracker. I believe there
should be means for the user community to be provided the tool, in this
case technical documentation, to enhance Request Tracker beyond what is
provided today.
Nick
PS If someone tells me how to put a tar file on the Wiki, I will be glad
to provide some of the reports and code enhancements I mentioned in this
message. I would include in the tar file, a copy of the reports,
modifications to Request Tracker/Asset Tracker, modifications to
RTx::Statistics, the Asset Tracker SSH scripts and the CGI scripts. I
also have a manual I wrote for installing Request Tracker at our site
including all the enhancements we made to the Request Tracker code. My
Management believes in contributing back to the Open Source community so
this would not be an issue. Hopefully, some of these enhancements and
changes will make it into Request Tracker 4.
Nick Metrowsky
Consulting System Administrator
303-684-4785 Office
303-684-4100 Fax
nmetrowsky@digitalglobe.com mailto:nmetrowsky@digitalglobe.com
DigitalGlobe (r), An Imaging and Information Company
http://www.digitalglobe.com http://www.digitalglobe.com
now, it’s only 3.6-default