ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Make issue reporter watcher of the issue (Feature #193)

Added by Felix Schäfer at 2011-02-14 08:28 am. Updated at 2011-02-17 08:23 am.

Status:Open Start date:2011-02-14
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Remote issue URL: Affected version:


I've never really understood why the reporter of an issue should mandatorily get updates for it. Instead of trying to solve that in the user preferences, I think making a reporter a watcher of the isssue by default (and maybe allow to opt out of being a watcher by default in the user prefs) would serve the same end and provides a way for reporters to opt out as needed.

Related issues

related to Feature #738: Option to automatically watch things I've interacted with Open 2011-11-29


Updated by Pedro Gutierrez at 2011-02-14 12:45 pm

I can't agree more.

Updated by Eric Davis at 2011-02-14 11:15 pm

I agree, making the issue author a watcher would let them step out of the issue later on.

Updated by Felix Schäfer at 2011-02-15 02:37 pm

This assigns the author as watcher instead of notifying him regardless of things:

 1diff --git a/app/models/issue.rb b/app/models/issue.rb
 2index 40b64f3..a73eda3 100644
 3--- a/app/models/issue.rb
 4+++ b/app/models/issue.rb
 5@@ -86,7 +86,7 @@ class Issue < ActiveRecord::Base
 6     }
 7   }
 9-  before_create :default_assign
10+  before_create :default_assign, :author_default_watcher
11   before_save :close_duplicates, :update_done_ratio_from_issue_status
12   after_save :reschedule_following_issues, :update_nested_set_attributes, :update_parent_attributes, :create_journal
13   after_destroy :update_parent_attributes
14@@ -432,9 +432,8 @@ class Issue < ActiveRecord::Base
15   # Returns the mail adresses of users that should be notified
16   def recipients
17     notified = project.notified_users
18-    # Author and assignee are always notified unless they have been
19-    # locked or don't want to be notified
20-    notified << author if author && && author.notify_about?(self)
21+    # The assignee is always notified unless she has been
22+    # locked or doesn't want to be notified
23     notified << assigned_to if assigned_to && && assigned_to.notify_about?(self)
24     notified.uniq!
25     # Remove users that can not view the issue
26@@ -793,6 +792,10 @@ class Issue < ActiveRecord::Base
27     end
28   end
30+  def author_default_watcher
31+    self.add_watcher author if author.present?
32+  end
34   # Updates start/due dates of following issues
35   def reschedule_following_issues
36     if start_date_changed? || due_date_changed?

I haven't found tests for the recipients, so this probably breaks nothing but isn't tested either. Eric, care to have a look around that/write a test for it?

Updated by Eric Davis at 2011-02-15 11:41 pm

Might want to update User#notify_about? also. That was part of my refactoring to have all notifications happen directly on the User object. Pretty sure it has some tests for it too.

Updated by Felix Schäfer at 2011-02-15 11:58 pm

That would be source:/app/models/user.rb#L415, and the change would make only_owner obsolete, only_my_events a duplicate of only_assigned and selected a "copy" of only_assigned, right?

Updated by Eric Davis at 2011-02-17 12:42 am

My goal with User#notify_about? was to have it support other objects too, some which have authors (forum messages, wiki edits). This is making me think, is there any object in ChiliProject that has email notifications that is missing watcher support?

Updated by Felix Schäfer at 2011-02-17 08:23 am

Eric Davis wrote:

This is making me think, is there any object in ChiliProject that has email notifications that is missing watcher support?

I don't think so. Maybe we can achieve the same goal by providing the ability for each user to decide on which actions to automatically become watcher globally and at project level, thus leveraging the already existing watcher stuff. That also has the added benefit that you can change your mind on single "objects" afterwards and would unify the "automatic watcher" behavior (doing stuff on an issue doesn't make you a watcher, doing stuff in a forum does).

Also available in: Atom PDF