Entries tagged request tracker

This week I have been primarily looking over ticketing systems.

So far I've looked at the following:

roundup

Initially this was the package that I liked best. It is small, self-contained, and easy both to install and manage.

The significant downside was that it expected all users to create an account first, prior to submitting a ticket. If they didn't and they mailed submit@example.org they'd receive a reply back which read "Unknown user: sender@example.net".

Shame because it was reasonably featureful.

otrs2

This was a little fiddly to get going with, but actually suprisingly good.

Had I not experimented with roundup I'd have said it were the best I looked at.

request-tracker

Big. Heavy. Intense.

It looks ugly, but provides a bamillion (metric) configuration options and can be used to do almost anything you'd like.

If it didn't such up so many resources I'd have had no qualms about using it. Even the mail-gateway was nice and simple to get working.

I'm going to take a look around some more and see if there are any non-packaged systems to look at. Pointers welcome.

All I want is for incoming emails to appear in some sort of queue where they may be assigned to an owner. If the original submitter can view the ticket online great, but no big deal if not.

I'd expect that replies sent to the ticket would be routed back to the submitter, and that replies to those would similarly update the ticket. I guess thats standard though?

Tags: otrs2, request tracker, roundup | No comments

So recently there have been a few posts by people discussing the idea of distributed bug reporting systems. This is topical, becuse I've been working on something vaguely related - a support system.

Why is a support system, or ticketing system, related to a bug tracker? To answer that you must first clarify what you mean by a support system (or a bug tracker for that matter). There are two distinct types of support systems:

"Full"

This is a system which does "everything". Each submitted support, or bug, request has an associated status, severity, priority and work log. It might be assigned to multiple people through its lifetime, and it might be moved around various internal queues.

Example: Request Tracker.

"Minimal"

A reported ticket is an email submission.

A "ticket" from start to finish is nothing more than a collection of mails upon a particular topic - there is no assigned "owner", no "priority", no object-specific attributes at all.

I've neither the time, patience, or desire to create any system like the first one. But I've become increasingly dissatisfied with my current support system, roundup, for various reasons. So I need something new.

Previously I ruled out several support systems and most of my objections still stand, although I admit I've not really looked again. I will certainly do so shortly.

So what have I done? Well I figure I care very little about queues, priorities, reports, and all that stuff. (On the basis that priority is mostly in the ticket itself, and that I'm the sole recipient of the submissions. Previously I had a partner to share them, but these days just me.)

I want something that is basically e-mail centric. That reduces the functionality of my support system to two distinct parts:

Ticket Submission

An email to sumbit@example.com should result in three actions:

A message being sent back to the submitter. "Hey got your ticket. We'll fix it. Love you long time.". (Set the reply-to address appropriately!)

A message to the site admin(s) saying "Hey, you've got a new ticket submission. Deal."

A new ticket being created/stored somewhere.

(There are additional nice things to have - such as SMS alerts outside 10:00-17:00, etc, but those are trivial bolt-ons.)

Ticket Updates

When a mail comes in to "ticket-XXXX@example.org" - which was setup in the submission process, or when a mail arrives with subject "[issueXXXX]" we need to append the correspondance to the existing ticket.

If that ticket doesn't exist we report an error. If the ticket is closed we re-open it.

So, what do we have? A script that is conceptually simple, and can be invoked via a pipe transport of Exim4. A script that just reads the submitted email from STDIN and only has to decide a couple of things based pretty much on the contents of the "To:" and "Subject:" headers.

Simple, no?

OK it was actually amazingly simple once broken down. The amazing part is that it all works. I figured that I'd manage new tickets by writing them to mbox files - simple to do. Simple to understand.

So the process goes:

• New email arrives to "submit@example.org"
• /home/steve/tickets/1 is created with the received message written to it.
• I get a mail to steve@steve.example.org.uk saying "new ticket!!!".
• I reply to the ticket by opening /home/steve/tickets/1 in mutt - where my muttrc ensures that when I reply the from address is the ticket address, and there is an automatic CC.
• The cycle turns, and more discussion happens until we're all happy the ticket is "done"..
• A mail to ticket-xxxx-done@example.org" closes the ticket by moving it from ~/tickets/ to ~/tickets/archived/.

There are a couple of helper scripts:

• ticket-close - close a ticket manually.
• ticket-list - show all open tickets
• ticket-view - open a ticket in mutt

But basically one script and mutt does it all.

So far it's been tested and it is rockin'! (Look at me, hangin' with the cool kids!)

Obviously it is pretty Steve-specific, and there is only a toy CGI process for viewing history online, but I'm actually feeling pretty good about it.

Once I've closed all my existing tickets I will probably migrate over to it. At least this handles (read: ignores) MIME - which makes it a clear winner of roundup, which just eats, bounces, or corrupts submitted multipart messages.

ObQuote: Flash Gordon

Tags: request tracker, roundup, support | 5 comments

About a year ago I was looking for a "support system", to allow people to report issues and then allow myself and my partner to handle them.

I looked at several packages and eventually decided upon roundup. (Minimal dependencies, included in Debian Stable, Simple to setup.)

Over time my annoyances with this package have grown, so its definitely time to look again at the support landscape. For the moment I decided to give in to pressure and try RT. Unfortunately this was very quickly the result:

[Tue Mar 17 18:54:23 2009] [crit]: <rt-3.6.7-5189-1237316062-367.1-3-0..>

Could not send mail: Couldn't run /usr/sbin/sendmail:
  Cannot allocate memory at
    /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm line 334.

Stack:
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:334]
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:288]
  [/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:107]

How much memory does the system have? 400Mb "real" and 256Mb "swap".

I've bumpted it up to 512Mb + 376Mb respectively. Lets see how that helps.

I'm reminded, once more, that in theory a support system is a small piece of software. In terms of my RT install all I did was install it, configure it such that when a new user submits a ticket they get back an autoreply with login details and can view/edit/close their own ticket via the web interface. This wiki page helped.

This is a step up from roundup which has a weird idea of security - if you allow a ticket submitter to use the UI they can see all open/closed tickets.

Anyway I'll keep testing it for a couple of days and if the memory helps then I guess its a small price to pay but .. ugh. Maybe the home made solution is the more practical solution..

ObFilm: Leon

Tags: oom, request tracker, roundup | 5 comments