Redmine

There's already a FR for this at #2964, as well as some discussion regarding this.

Not exactly, #2964 is about assigning the issue to multiple users. I read the discussion about it. Right now, there can be only one asignee of an issue and having suddenly several raises indeed some questions.

With observers, there is already the option to add multiple to one issue. My request is about being able not only to add users as observers but entire groups. We often have support issues which several employees of our customer want to follow. Adding them one by one to each issue is a bit of a hassle. I would like to be able to just create a group and add this group as observer.

Michael Ruder wrote:

Not exactly, #2964 is about assigning the issue to multiple users.

Oh, sorry, I misread that you wanted to assign an issue to a group, not make a group observe an issue. My bad.

this is is think is a really good idea, will save a lot of time

I think also this a good idea, will help us a lot!
I vote for this! +1

I join and vote too.
Very necessary functional, IMHO

+1

+1

+1

Would be very functional, will really reduce timecost for big projects... +1

got this request as issue in our company. Gonna try to make it as a plugin, when done i'll post it here.

Got this done as a plugin(It is on a Plugin Page) so you are free to check it out.

We decided to do it by Roles, they are easier to modify and can be assigned per Project per User.
It Adds new Permission to the roles page Display in selection so when this is checked and there are some users in this role on that project, it shows in the list.

Also added Sellect All and Unsellect all buttons.

• +1.
• Difference between Watcher Selection by Role and Watcher Selection by Group seems interesting. Thank you Milan.
• Compatibility with versions above 1.0 is untested. Is there any risk in testing ? If trying features on a local copy of my Redmine 1.2 production setup seems to work, is there any risk in pushing that to actual production ?

+1

+1

"almost 3 years". But feature is really worth to be done. So +1.

Badly need this great feature for big project! +1

+1 this feature would be really helpful!

+1 very useful

+1 It would really speed up our ticket creation.

+1

Watcher Selection by Group does not work expectedly on my installation of Redmine 2.2.

I wrote my edition of similar plugin which helps checking watchers by their group. Not yet well tested, but it's working on my Redmine 2.2.

http://www.redmine.org/plugins/watcher_groups

+1

http://www.redmine.org/plugins/redmine_watcher_groups - in difference from other solutions, with this plugin notifications are sent to current group members.

+1. This is necessary.

+1

+1

When I have to add 1-2 observers its ok. When I need to add a department which is ~10-15 users and is already at one group this becomes really useful.

K. F. wrote:

http://www.redmine.org/plugins/redmine_watcher_groups - in difference from other solutions, with this plugin notifications are sent to current group members.

Hi, is this plugin availabe (or will be available) for version 2.4.x ?

The above plug-in has one pitfall, it does not allow for proper "watcher" search queries : suppose I want to build an issue listing query for which tickets I am watching, from /issues/, at this stage, using this plug-in only shows issues where I (as a User) am explicitely set as a watcher, but does not take in account Groups.

• works properly with Postgres, now (Removed the ` MySQL-ism from the SQL queries)
• stores journal entries for watcher groups added/removed to ticket
• has a Japanese locale
• coordinates with the Redmine People plug-in from CRM to list group members

However, given it merely relies on the assumption that a Group and a User are deep down the same object, and the Principal->{User,Group} class inheritance to make things works, but basically shoves something in the watcher table that was not endorsed by Redmine via a raw SQL query, this means that for every Redmine upgrade, I have to be especially careful that this design axiom remains true. This sort of feels like a feature that should be built inside of Redmine core, and not as a plug-in.

I currently have a request from my company to implement a watcher query that takes in account watcher groups (which is of course very easy to do since this already works for tickets assigned to a group) :

--- app/models/query.rb.old    2014-10-21 12:21:55.601988870 +0900
+++ app/models/query.rb    2014-10-21 12:22:22.994264149 +0900
@@ -546,7 +546,7 @@
         if v.delete("me")
           if User.current.logged?
             v.push(User.current.id.to_s)
-            v += User.current.group_ids.map(&:to_s) if field == 'assigned_to_id'
+            v += User.current.group_ids.map(&:to_s) if field == 'assigned_to_id' or field == 'watcher_id'
           else
             v.push("0")
           end

Basically what this change does is, get the list of watchable issues from the watchers, when the watcher "user_id" is actually all the group_ids behind that user. This would not impact normal operation, as the Redmine current model does not allow addition via API of anything besides Users to the watchers table.

• Method override would mean playing catch-up with core code just to add a "or" condition here
• Chaining alias are only really efficient for pre or post processing, and not usable here

+1

Stephane Lapie wrote:

The above plug-in has one pitfall, it does not allow for proper "watcher" search queries : suppose I want to build an issue listing query for which tickets I am watching, from /issues/, at this stage, using this plug-in only shows issues where I (as a User) am explicitely set as a watcher, but does not take in account Groups.

I have made my own customized version of the watcher groups : https://github.com/darksoul42/redmine_watcher_groups which also :

• works properly with Postgres, now (Removed the ` MySQL-ism from the SQL queries)
• stores journal entries for watcher groups added/removed to ticket
• has a Japanese locale
• coordinates with the Redmine People plug-in from CRM to list group members

However, given it merely relies on the assumption that a Group and a User are deep down the same object, and the Principal->{User,Group} class inheritance to make things works, but basically shoves something in the watcher table that was not endorsed by Redmine via a raw SQL query, this means that for every Redmine upgrade, I have to be especially careful that this design axiom remains true. This sort of feels like a feature that should be built inside of Redmine core, and not as a plug-in.

I currently have a request from my company to implement a watcher query that takes in account watcher groups (which is of course very easy to do since this already works for tickets assigned to a group) :
[...]

Basically what this change does is, get the list of watchable issues from the watchers, when the watcher "user_id" is actually all the group_ids behind that user. This would not impact normal operation, as the Redmine current model does not allow addition via API of anything besides Users to the watchers table.

Given that this code change is located within a loop used to create the SQL query for the search, it can not realistically be implemented with a plugin :

• Method override would mean playing catch-up with core code just to add a "or" condition here
• Chaining alias are only really efficient for pre or post processing, and not usable here

I just installed the plugin. Why can I only assign a user group when the issue is already reported?

It would be nice if I can assign a group when I report a new issue.

+1

If you are looking for a watcher group plugin working at issue update AND at issue creation you can take a look at Alexei Margasov fork of redmine_watcher_plugin : https://github.com/nauphone/redmine_watcher_groups

It's working in my redmine 2.6.1 install.

The group is not notified on the ticket creation though.

Benjamin Baumann wrote:

If you are looking for a watcher group plugin working at issue update AND at issue creation you can take a look at Alexei Margasov fork of redmine_watcher_plugin : https://github.com/nauphone/redmine_watcher_groups

It's working in my redmine 2.6.1 install.

as well as on 2.3.4.stable.

The group is not notified on the ticket creation though.

And all groups are visible/selectable without taking into account their restriction to certain projects (on issue creation and when adding watchers).

Maybe someone could use the work done in chiliproject to back-port to Redmine.

See: https://www.chiliproject.org/issues/802

I make modifications to redmine_watcher_groups plugin to run it with Redmine 3.1.1.
See [[https://github.com/foton/redmine_watcher_groups.git]]

Up, and a little update.
I updated upon Petr's plugin for Redmine 3.3.3-stable.

Here is my fork, but I also filled a pull request to his repository for good measure.
https://github.com/darksoul42/redmine_watcher_groups

It seems there is one aggravating edge case, as the acts_as_watchable code uses and expects a ActiveRecord_Associations_CollectionProxy (calls to the reset() method), and the current code degraded it as an array, I tried a quick and dirty hack.

Return the array, but with a method that takes in the initial object within its context, and calls the original reset() method.
Hopefully this does whatever cleanup is expected, but still functions properly.

I am more and more convinced that such a deep change should be handled internally by Redmine, instead of going through an arms race with plugins...

Stephane Lapie wrote:

I updated upon Petr's plugin for Redmine 3.3.3-stable.

Stephane, thanks for your efforts.

Here is my fork, but I also filled a pull request to his repository for good measure.
https://github.com/darksoul42/redmine_watcher_groups

I installed your fork on a Redmine 3.4.0 instance, and it's causing problems there. Adding a watcher group work likes expected. Also, I can add an user as watcher (core Redmine functionality). If I try to delete the user I just added, Redmine server process exits silently. Maybe you can have a look into this?

Andreas,

I just had a look into that, and found that the ActiveRecord_Associations_CollectionProxy object does remain as such (and not degraded into an Array) when there are no watcher groups. Therefore in that case, I should not be defining the reset() method, which would trigger an endless recursion loop and a stack overflow. I suppose this is what you have seen, but could you confirm?

The fix is committed to my github.

+1

Stephane,

Thanks for this great plugin. I installed on fresh 3.4.2 instance, but autocomplete function not worked for me.
I changed this line in watcher_groups_controller.rb from:

@groups = Group.active.like(params[:q]).find(:all, :limit => 100)

to:

@groups = Group.sorted.active.like(params[:q]).limit(100)

and autocomplete function started to work.

Ah, I see, this must have been an older API call I had missed.

I just integrated it.

Thanks!

Stephane Lapie wrote:

The fix is committed to my github.

Stephane, thanks for your efforts.

I suppose this is what you have seen, but could you confirm?

I just installed the master of your github project on an fresh Redmine 3.4.2 instance, and yes, I can confirm that the plugin is working now. That's great!

As far as I can see, there's still a small glitch here. Here is the way to reproduce:

1. Open an existing ticket with no watchers defined.
2. In the right bar, click on "Add" (right beneath the heading "Watchers group") to add a watcher group to an existing project. All persons of the watcher group are instantly shown as watchers. That's perfectly fine.
3. In the right bar, click on "Add" (right beneath the heading "Watchers") to add a single person as watcher. The person is added as watcher, but does not show up instantly in the watchers list. If I reload the page, the person appears in the list of persons watching the issue.

The good thing is that the person is actually added, so it's merely a display issue. Nevertheless, this behaviour might confuse users.

Note: The same applies if I delete an existing watcher (single person) by clicking on the trash bin symbol. The person is only removed from the watchers list after reloading the page.

cleber souza wrote:

Stephane Lapie wrote:

Up, and a little update.
I updated upon Petr's plugin for Redmine 3.3.3-stable.

Here is my fork, but I also filled a pull request to his repository for good measure.
https://github.com/darksoul42/redmine_watcher_groups

It seems there is one aggravating edge case, as the acts_as_watchable code uses and expects a ActiveRecord_Associations_CollectionProxy (calls to the reset() method), and the current code degraded it as an array, I tried a quick and dirty hack.

Return the array, but with a method that takes in the initial object within its context, and calls the original reset() method.
Hopefully this does whatever cleanup is expected, but still functions properly.

I am more and more convinced that such a deep change should be handled internally by Redmine, instead of going through an arms race with plugins...

Thanks Stephane for this version of the plugin, but in the version of Redmine 3.4.4 stable. The Plugin is installed normally, but when it will access the task screen the error below is displayed.

Resolved compatibility version: https://github.com/piccio/redmine_watchers_groups

+1

cleber souza wrote:
...
Resolved compatibility version: https://github.com/piccio/redmine_watchers_groups

Hi Cleber Souza

I installed the plugin you provided for Redmine v3.4.4.stable, it works for creating issues with groups watchers, but when I open the issue I just created, the ruby process takes CPU 100%...I have to uninstall it, do you know what should be the issue?

I fixed the CPU 100% issue of Cleber Souza codes

Redmine 3.4.4.stable
Original: https://github.com/piccio/redmine_watchers_groups

Fixes

diff --git a/lib/redmine_watchers_groups/group_patch.rb b/lib/redmine_watchers_groups/group_patch.rb
index 567f2a0..a3a7bb8 100644
--- a/lib/redmine_watchers_groups/group_patch.rb
+++ b/lib/redmine_watchers_groups/group_patch.rb
@@ -22,7 +22,17 @@ module RedmineWatchersGroups

         unless watcher_ids.empty?
           # simple combinations of watchers
-          simple_watchers_combinations = watcher_ids.repeated_combination(watcher_ids.length).to_a.map(&:uniq).uniq
+          # FIXME: CPU 100%, producing too many combinations
+          # simple_watchers_combinations = watcher_ids.repeated_combination(watcher_ids.length).to_a.map(&:uniq).uniq
+         users = User.where(id: watcher_ids)
+         dict = {}
+         users.each do |user|
+           user.group_ids.each do |gid|
+              ids = dict[gid].to_a.push(user.id)
+              dict[gid] = ids.uniq
+            end
+          end
+         simple_watchers_combinations = dict.values

           simple_watchers_combinations.each do |simple_watchers_combination|
             # the first query find all groups that contains all the current watchers as members through
@@ -48,4 +58,5 @@ module RedmineWatchersGroups
     end

   end
-end
\ No newline at end of file
+end
+

+1 to have it implemented as a standard feature

Sunding Wei wrote:

I fixed the CPU 100% issue of Cleber Souza codes

Redmine 3.4.4.stable
Original: https://github.com/piccio/redmine_watchers_groups

Fixes
[...]

This plugin crashed the tickets where I used a group as observer. see https://github.com/piccio/redmine_watchers_groups/issues/4

and +1 to have it as a standard feature

+1 to have it implemented as a standard feature.
We used the https://www.redmine.org/plugins/rmp_group_watchers plugin until now but since updating to V4.x the plugin isn't longer useable

+1

Marius, thank you for improving the code but I noticed that 0001-Get-the-list-of-new-issue-watchers-using-single-quer.patch change the behavior.

Redmine 2.5 or later does not show watchers checkboxes on the new issue page when more than 20 members belong to the project (#8562). However, after applying the patch, first 20 members/groups are displayed even when the number of members exceeds 20.

Regarding first problem (N+1), we don’t do anything?

I just need to add groups as watchers like regular user. I tried patches shared in this issue but none of them are applicable for 4.0 version.

if subject.present?
    self.add_watcher(project.default_assigned_to) unless watched_by?(project.default_assigned_to)
end

Our project default assignees are groups. The custom workflow code above doesn't work because, Redmine 4.0 doesn't accept groups as known type for watchers.

There seems to be a bug in this feature - groups added as watchers are shown as text, not as links (like in Overview panel or like when adding users in watchers or when setting a group as assignee). Consequently, you can't see members of the group on the ticket)

I created a ticket for this: #37958