Hopefully most of you don't have the need to visit our bug tracker enough to have noticed, but we recently switched from a third party application for managing our bugs to IP.Content.
The history of the software we used to use for our bug tracker goes back quite a bit. It was originally written by Matt, many years ago - before that we used regular forum topics as bug reports!
A couple of years ago, around the time IP.Board 3.0 was released, we handed over the codebase to a group of volunteers who wanted to develop the bug tracker application further - and they did.
The developers have done a fantastic job with Tracker, however since then we've released IP.Content, our own application which lets you create (amongst other things) custom databases.
We decided that since moving forward it's definitely easier for us to be using our own applications (otherwise we have issues whenever we upgrade this site to beta software) especially as soon we'll be developing them all under one release cycle, and IP.Content is more than capable of handling the task, to switch from Tracker to IP.Content.
So what did we do to turn IP.Content into a fully featured bug tracker? Actually, nothing special!
IP.Content's databases already have support for categories (we created one for each product) and custom fields (we created fields for "status", "version" and "fixed in version"). We didn't need to do any skinning either - the default database templates work fantastic for a bug tracker. We also took this opportunity to have one of our non-technical members of staff create the database. This gave us some great ideas on improving the system for ease of use.
In fact, there was only 3 hurdles we had to overcome:
1. Filter Bars
When you're working through bug reports you only really want to see open bug reports - we needed a way to filter the records being shown created on the custom "status" field we'd created.
After thinking about the best approach for this, we realised that there's probably other uses for IP.Content which also might benefit from fields being "filterable". So we went ahead and added the feature to IP.Content.
When the next version of IP.Content is released, any enumerable field type (dropdowns, radio boxes, checkboxes) will be able to be selected as "filterable".
When viewing records you'll then see a sidebar allowing you to select one or more of those values to filter the records by.
This is what it looks like in our new bug tracker:
2. Quick Changing Fields
Unlike most database uses, in a bug tracker, you need to be able to change the record's data (status, fixed in version) quickly - and often at the same time as making a comment on the report.
We decided for this we'd need to write some code specifically for our needs. Fortunately, IP.Board's hook system makes this really easy.
In case anyone out there is feeling particularly geeky and wants to know how this works, the hook has 3 parts:
- A skin overloader which adds dropdown boxes above the comment form
- A data hook which intercepts the comment being added and updates the records data based on the dropdown box values. It also edits the comment that was posted and adds in "Updating Status to: X", or whatever was changed.
- An action overloader which stops an error being thrown if the comment is empty.
In total, the hook is just 81 lines of code and took about 30 minutes to write.
3. Moving the data
Our final hurdle was converting the data (for which I whipped up a CLI script).
Naturally, we also had to make sure that old bug report links gave HTTP 301 redirects to the new reports - wouldn't want our SEO to suffer!
To do this, I just dropped a few lines of code in one of the old Tracker source files.
So here it is, our brand new bug tracker, completely powered by IP.Content.
Read more about IP.Content or try it for free.
If you have any questions about what IP.Content can do, shoot us an email - we'd love to hear from you.