Posterous theme by Cory Watilo

Patching Redmine 0.8.x for email notifications on added news items regardless of user notification settings

That’s a mouthful.

Redmine 0.8.x does not send email notifications about added news items unless the user’s notification settings are set to permit updates about everything in the project, including all issue updates, etc.  This isn’t a very happy medium.

There is a ticket, #2549 at redmine.org that describes a “watch” feature for the news feed.  This would be ideal.  Since no real action seems to have been taken on it in the last year, I found a way to patch (read: hack) a dumb notification feature into the code.  I provide no warranty for this, it’s provided AS-IS.

The idea is that instead of sending to a project recipient list that has been filtered for users not wishing to see all notifications, to instead simply send to all project members.  To do this, I added a new method to the projects class which provides this unfiltered email list.  It requires two patches:

=== (+2,-2) apps/redmine/app/models/mailer.rb ===
@@ -101,7 +101,7 @@
   def news_added(news)
     redmine_headers 'Project' => news.project.identifier
-    recipients news.project.recipients
+    recipients news.project.news_recipients
     subject "[#{news.project.name}] #{l(:label_news)}: #{news.title}"
     body :news => news,
          :news_url => url_for(:controller => 'news', :action => 'show', :id => news)

and:

=== (+5,-1) apps/redmine/app/models/project.rb ===
@@ -205,6 +205,10 @@
     members.select {|m| m.mail_notification? || m.user.mail_notification?}.collect {|m| m.user.mail}
   end
+  def news_recipients
+    members.collect {|m| m.user.mail}
+  end

   # Returns an array of all custom fields enabled for project issues
   # (explictly associated custom fields and custom fields enabled for all projects)
   def all_issue_custom_fields

 

The second change create a new method, “news_recipients”, which is simply the email list of group members.  The first change makes the news_added event use the news_recipients list instead of the project’s regular recipients list.

This is a very naive approach, isn’t sanctioned by anyone, including me, and could easily have problems I don’t understand.  For example, I have no idea what this does with project members who have been locked out in the administration interface.  If security and privacy are important to your organization, do not use this patch.  You've been warned.

On a side note, I use Mercurial’s MQ extension to maintain such patches to source code on a production system.  This allows me to run with the patches until upgrade time, then to lift and reapply the patches after the upgrade process completes.