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