Posts Tagged ‘request tracker’

A comparison of Request Tracker version 3.8.4 to Redmine version 1.0.4.

This evaluation preceded scripting a migration between the two systems.


This targets the general features in Redmine vs. Request Tracker and is not a comparison of custom variables, or configuration options. This is not an exhaustive list; this was written as a simple comparison of basic issue tracking features between Request Tracker 3.8.4 and Redmine 1.0.4.

Features unique to Redmine

More than just a ticket tracking system

Request Tracker excels at one thing, ticket tracking. Redmine is an issue tracking system and has additional modules available.

  • Time tracking
  • News
  • Documents
  • Files
  • Wiki
  • Repository
  • Forums

Features unique to Request Tracker

Reply to closed ticket re-opens it

In redmine replying to a ticket does not change the status.

Outgoing e-mails stored

Request Tracker tickets show an entire chain of events, including all automated e-mails with full headers. In experience, occasionally useful.

Comment vs. Reply to requester

Request Tracker has a concept of replying to requester and making comments on an issue. Redmine will send update e-mails for every comment, regardless of content.
There is an open feature request for private comments that addresses this issue.

Redmine Stealth Plugin to temporarily disable notifications on actions taken by a user.
It is ajax based, so if I wanted to make a comment on an issue that sent no notifications; I would click the Enable Stealth Mode link, take my actions, then Disable Stealth Mode after I’m done.
Again this is user based, so it does not affect other actions taken by other users.

There is an open request on Redmine for functionality similar to this:

Ticket Requester

One of the more advanced features of Request Tracker was the People section. Request Tracker stored who created the ticket, who owned the ticket, and requesters of the ticket. Created is a searchable, but essentially hidden attribute of a Request Tracker ticket.
This allowed Request Tracker users to create a ticket for a user, and assign them as the requester. This is not possible in Redmine.

Redmine only stores Author (Request Tracker – creator). The only way to get an issue created with the proper author is for that person to create it via e-mail or by logging in.

Open feature request to change that:

Merge Tickets

In Request Tracker when a ticket was merged with another, only one ticket existed at the end of the process. The original ticket number would point to the ticket it was merged into, and the content from the merging ticket would appear in the merged ticket.

This was useful for joining several e-mails that were related to one ticket.

In Redmine you can only link related tickets by adding a duplicates or duplicated by related issue. This will only establish a link between the two issues, not copy content from one to another.

Also, there is a standing practice to find the duplicate ticket and close it, so time/comments/updates are logged against one issue.

There are a few standing feature request for this functionality

To accomplish the same concept as Request Tracker “merge” mark multiple Redmine issues duplicates and update the most recent ticket as the “active” one.


In Request Tracker you could attach reminders to tickets that would show up on your main page. Reminders could have a date and subject. There is no concept of this in Redmine.

At best comments can be made against an issue, or watch an issue.

NOTE reminders live in the tickets table as rt3.tickets.type = ‘reminder’ so they could be converted as pseudo tickets if needed, related to the attached ticket.

Ticket Status ‘delete’

In Request Tracker tickets could not be deleted. A status of ‘delete’ only meant the ticket was hidden from the gui, but can still be accessed via direct ticket number input, and still existed in the database.


For just issue tracking, both systems offer lots of features. However for me Redmine takes the cake with the larger feature set of project management.

Read Full Post »

If there was any one thing that drove me nuts about Request Tracker (3.8.4), it was the date picker.

It’s 2011 and it still uses a new pop-up window to display a calendar for choosing dates.

Read Full Post »

The last two weeks have been focused on learning ruby to write a rake task that would migrate data from Perl based Request Tracker(TM) to a RoR based Redmine issue tracking system.

I’m happy to report (and sad I didn’t post incremental updates on my experiences with ruby) that I have released a beta rake task that goes 90% of the way.


Needless to say there are countless ways this could be improved and cleaned up. I hope that others find it useful, and I am happy to have ‘contributed’ back to the community for once.

My summary of RoR is its nice to be working in a class based, object based MVC architecture. Don’t know if 4D will ever get there.

Read Full Post »

%d bloggers like this: