About Archive Tags RSS Feed

 

He'll save every one of us!

10 July 2008 21:50

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 [email protected] 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 "[email protected]" - 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 "[email protected]"
    • /home/steve/tickets/1 is created with the received message written to it.
    • I get a mail to [email protected] 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 [email protected]" closes the ticket by moving it from ~/tickets/ to ~/tickets/archived/.

    There are a couple of helper scripts:

    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

     

    Comments on this entry

    icon Legooolas at 21:24 on 10 July 2008
    Whilst you say that you don't want something like "Request Tracker" you then appear to describe something which is almost exactly that :) The default install of RT, with some email address settings and a way to get the email into RT (some address which gets there via fetchmail or by being the endpoint of the mail address and an MTA), does exactly the three things you say, and has a scrip[t]s system to do things such as the SMS alerts. And a web interface with all the history, and graphs for stats etc. What is it that you really dislike about [systems like] RT that makes you want to write a script and have the same problems as they have already solved? (not that I'm saying you shouldn't just that this appears to fit perfectly)
    icon Steve at 21:28 on 10 July 2008

    I ruled out using RT on the grounds that it is too heavyweight.

    (Both in terms of the resources required; and in terms of the setup, and usage of it. I dont need queues, priorities, merging, linking, or a web-history).

    I guess the point of this blog post is basically:

    There are two types of support systems; heavyweight like RT, and simple. Here's a simple one which is tailored just for me.


    icon Don Armstrong at 05:09 on 11 July 2008
    Congratulations, Steve Kemp!
    You've implemented Debbugs!
    [What you're describing is almost exactly how debbugs works; you could pretty easily install an instance on your system with the automatic default package patch I added for emacs, and you'd be done, and would have all of the neat integration bits that debbugs gives you.]
    icon Alex at 00:56 on 13 July 2008
    Wow, I didn't realise commenting had become such a sarky art. That's one bandwagon I'd rather not hop onto, thanks :)
    icon Steve at 17:37 on 14 July 2008

    Sarcasm always welcome. Along with silver, irony and goldy!

     

    Created by ephemeris.

    © Steve Kemp