DjTracker First Release

A couple of weeks ago, I decided I wanted a solid, free, open source issue tracker. I’ve tried Trac, Mantis, and Bugzilla before, none of which have left me exceptionally pleased. Bugzilla is a nasty mess of Perl, ugly to look at, and difficult to navigate. Trac isn’t too bad, but I hate to administer it, and find that finding issues after they’ve been submitted to be more problematic than I like. Mantis is actually really good, and I like it quite a bit. My biggest concern with it is that it’s absolutely hideous to look at, and it’s not incredibly intuitive on how to make it look at least presentable. Redmine is supposedly another great option, one that I should have explored, but I didn’t want to deal with a Ruby stack on my machine too much.

I looked around the Django community, and didn’t see much in the way of stable/active issue tracking projects. It’s completely possible that I missed one or something, but the twitterverse didn’t turn up much in the ways of Django based issue trackers either. Now, it goes without saying that I love JIRA, and think it’s probably the best issue tracker out there for the price. However, it’s not free, and not open source, so it’s excluded from this discussion. As a result, I decided I’d make myself a simple issue tracker, built on the Django framework. After a couple weeks, I have something that I consider to be fairly presentable, DjTracker. You can skip straight to the good part, and look at the demo if you want. It’s a fully functional instance with a bunch of test data.

Going into this, I had to think of what I felt was most important to me in an issue tracker. First off, I feel you should have “Projects” with issues grouped into those projects. Secondly, I felt there are various pieces of a project, of which you’d like to further group your issues. For instance, projects can have components, different versions, and so on. Third, I felt it was important that the user could define their own Priority types, and their own Status types quickly and easily. Fourth, I felt user permissions and protecting data was going to be absolutely crucial. Finally, what good is an issue tracker if you can’t find the data quickly?

With that list of core ideas, I set out to tackle the issue, to build an issue tracker that first and foremost, I wanted to use (ironically, I’m not using it in any fashion yet). The first couple of goals on my list were fairly simple and straightforward. With DjTracker, you create a project, along with optional components, versions, and milestones. These will help you group and track progress on various projects that you create. Priority types and status types are both just simple models in Django, enabling you to create new ones via the administrative interface. Too many trackers I’ve used before dictate what my status/priority types are. I setup some default ones for you, and assume that a “closed” status will exist. You can configure further as you feel necessary.

Now, the permissions were somewhat interesting. Django doesn’t have a built in method for row level permissions, so I hand crafted these permissions. Users can be given permissions based on “view”, “comment”, or “modify” per project. Viewing permissions simply let you browse a project, comment permissions allows you to create and comment on issues. Modification permissions allows you to modify an issue, such as closing an issue. These permissions can be assigned to all viewers of the site, all authenticated viewiers, specific users, and specific groups, or you can mix and match as

you see fit.

In order to let you find your issues, you can browse by project, by project component, version, component, status, or priority. You can also use the issue filter to mix and match these items to get a specific list of issues. Let’s say you need all issues for Milestone A, Component B, Version 1, with a status of Open, and priority Critical, you can do that. Furthermore, you can save that filter for future use, and it’ll appear on your dashboard for reuse. Also on your dashboard will be a list of recently updated issues, issues you “watch” (more on that in a moment), issues assigned to you, and issues you’ve created. Watching issues allows you to receive automatic email updates on a specific issue. If someone comments on an issue you watch, you’ll receive an email about it.

One extra feature I felt was important was to be able to poll a VCS for updates to issues. Hence, I added the ability to assign a Git or SVN repo to a project. You give it the path, and the current commit hash (number in SVN’s case). Then you setup a cron job to run the management commands, and it’ll parse commits for the string “Fixes #ISSUE_NUMBER” such as “Fixes #15”. If it finds that, then the issue with an ID of 15 will be updated and closed out. This is a fairly new feature to the list, and will receive more improvements as time goes on.

Obviously, I don’t claim DjTracker to be bug free, and as a result it’ll continue to receive continous development. It is licensed under the BSD license, so you’re free to use it as you please. Of course I’m always welcoming committers as well. You can find the repo here, and the README here.