One thing that has been done very successfully for an RT implementation I have done in the past, is reports generated via MS Access.
I know, I know… the dark one cometh…
The scenario was essentially similar for me, but I was -very- disinterested in making reports happen. Especially for management who were very pro Microsoft. The answer we chose was that a Read-Only account was set up in the MySQL database, and then the managers in question could query the DB using their Microsoft Access clients.
This worked very well, because it allowed them to fully view what was going on in the ticket management system, without them having any ability to modify anything. They could then use all of the gooey goodness (pukes) in MS Access to generate their Crayola Compliant management reports.
The thing that was the biggest pain, was deciphering the schema of the database for RT. We found an old schema diagram, but even then we had to essentially decode it from scratch. (Here’s a suggestion for you Jesse. It would be extremely useful at times to have a full Entity-Relation Model data diagram showing the RT schema and its relationships. As I said there is an older diagram floating around, but its a long way from an ER model).
From: email@example.com on behalf of Todd Chapman
Sent: Sat 11/5/2005 2:39 AM
To: Hersker, Steve
Subject: Re: [rt-users] Reports
On Fri, Nov 04, 2005 at 09:37:21AM -0500, Hersker, Steve wrote:
Against my will and better judgment, I have to run weekly reports for
management to review (for regulatory compliance). A list of all open & new
tickets (with details and complete ticket history for each) and all tickets
closed the previous week (again with details and history) are two examples.
Before I can put RT in production, I have to find a way to generate these
reports. Has anyone done anything similar? If anyone just has the generic
SQL statement(s) that puts together the ticket, transactions and
attachments, I’d appreciate it.
That sounds unpleasant.
You should never try to access RT data by going to the database
directly. The perl API is the preferred method.
One option you might want to consider is writing a program that
can drive a web browser to run the queries and print each ticket.
It would look nicer than text reports, and you wouldn’t have to
worry about the Perl API. Just a thought.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Buy your copy of our new book, RT Essentials, today!
Download a free sample chapter from http://rtbook.bestpractical.com