Redmine is a very lean and powerful web application for project management. GOYELLO is using it for managing all different client projects. Recently we realized that the email notification mechanism could be improved to reduce the amount of spam sent to the team members. Read further to learn how we managed to do it, and besides we will share our plug-in with you!

Although the tool is excellent, it has some shortcomings. Take for example the Redmine mail notification system. As some users already reported at Redmine forum, after the mail notification is set, it will send mail messages of issue changes even if someone is not changing anything (e.g. simply created an issue). Nor is it possible to stop mailing feature for users that completely do not need it, but are involved in the project and notifications are just spamming their mailbox. Below you will find a screenshot of my mailbox with several emails sent from Redmine on a daily basis.

Redmine itself doesn’t allow us to configure in more robust way when we would like to be notified.

Here we have two options:

• “For any event (…)” which means, that Redmine will inform of any change on the issue, whether the person is assigned to the issue or not.

• “Only for things I watch or I’m involved in” which gives some relief, but means that Redmine will still be sending messages to a creator of an issue (and that will probably mean all issues if someone is project manager), also watchers will get mails, whether they like it or not.

This last little option speaks for itself. If you are the one that is changing an issue, then Redmine can spare you the overwhelming amount of notifications. But if one of developers updates the issue that PM created (even though he is not assigned to it), he will still receive the spam.

Despite all its shortcomings, the tool is very important so we couldn’t let this tool be idle and unused, so we created a little fix for it. It comes in the form of a plug-in, but requires some changes in core files in order to run properly. They are as little and neutral as possible, so there is a minimum risk that it will ever get in conflict with the original functions. These code changes are actually hooks and even if the plug-in is removed, it won’t affect the Redmine’s work.

Here’s how it looks when the plug-in is added and working.

On “my account” page you can see two more checkboxes– the upper one is for users who don’t want to be notified when the issue change doesn’t apply to them. The bottom one disables sending mail notification at all. With this option a project manager, a client, or any other person involved in the project should now feel safe from the notification harassment. It is possible to shut down notifications completely, but if someone, whose name is on the issue, wants to be notified by email it won’t be a problem either.

By how much can we reduce the amount of emails?

If you are a project manager working with Redmine, you probably know how this notification spam can make your life unbearable. For those who do not fully realize the seriousnes of the problem just imagine a project that has 20 issues for one phase. Let’s assume you are a PM of this project, and cooperate with two other people. You created all those issues, and now for every stage that the issue passes you receive an email. If there are three statuses, this can generate up to 60 emails only in the first phase. What if you had a serious project, with at least 40 open issues and workflow extended to 15 statuses?

In this way you can limit the amount of auto emails sent from Redmine

If this suits your needs, here’s how to install the Redmine plugin:

1. Download the plugin from: http://github.com/GOYELLO/Redmine_Mail_Configuration_plugin/tree/master

2. Copy the content to the RedmineRoot\vendor\plugins\

3. Run patch that can be found in redmine_mail_configurator\patch\ folder

(this means that you will have to use some svn tool [like tortoise], or Cygwin, or you have linux, and you’re the happy one. Lastly you can use text editor to open the diff file and add changes by yourself. There are only two lines of code to be added in two files)

4. You should be able to see the changes by now, if you run Redmine again.

(Command rake db:migrate_plugins RAILS_ENV=”production” is not needed here as there are no database changes in this plugin, so it won’t do much)

Now you are ready to go. Any time you want, you can be the master of your mail again.

We also created some other interesting “little fixes”. They can be found here.

If you have any questions about working with Redmine don’t hesitate to ask. Share your experiences with us as well.