Feature #4511

Allowing to add user groups as watchers for issues

Added by Michael Ruder almost 8 years ago. Updated 4 months ago.

Status:NewStart date:2010-01-01
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:

Description

Having the nice user group feature in Redmine 0.9, it would be very handy to be able to add whole group as observers for issues. Currently, only user accounts can be added as observers.


Related issues

Related to Redmine - Feature #10121: Watchers - Add Group / Role New
Related to Redmine - Feature #13513: Personal watch note on issue New
Related to Redmine - Feature #4244: Multiple email addresses for each user Closed 2009-11-19
Duplicated by Redmine - Feature #24943: Issue watchers to have groups in addition to users Closed

History

#1 Updated by Felix Schäfer almost 8 years ago

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

#2 Updated by Michael Ruder almost 8 years ago

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.

#3 Updated by Felix Schäfer almost 8 years ago

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.

#4 Updated by Eric Davis almost 8 years ago

  • Subject changed from Allowing to add user groups as observers for issues to Allowing to add user groups as watchers for issues
  • Category changed from Groups to Issues

+1 I would expect they would be added and removed as a group as opposed to adding them as a group and having to remove each member.

Example:

  • Add GroupA - (Developer1 and Developer2)
  • Remove GroupA

#5 Updated by Pavel Smirnov almost 8 years ago

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

#6 Updated by Alain V. almost 8 years ago

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

#7 Updated by Serge Kosse over 7 years ago

I join and vote too.
Very necessary functional, IMHO

#8 Updated by Enrique Delgado over 7 years ago

+1

#9 Updated by Marcelo Fernandes over 7 years ago

+1

#10 Updated by Nicholas Kulikov over 7 years ago

+1

#11 Updated by Novikov Igor over 7 years ago

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

#12 Updated by Milan Stastny about 7 years ago

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

#13 Updated by Milan Stastny about 7 years ago

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.

#14 Updated by Stéphane Gourichon over 6 years ago

  • +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 ?

#15 Updated by xianguo wei almost 6 years ago

+1

#16 Updated by M. K. almost 5 years ago

+1

#17 Updated by Arthur Zalevsky almost 5 years ago

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

#18 Updated by Wan Zhenhuan almost 5 years ago

Badly need this great feature for big project! +1

#19 Updated by Maik Lindner almost 5 years ago

+1 this feature would be really helpful!

#20 Updated by Fred Giusto almost 5 years ago

+1 very useful

#21 Updated by Davy Tielens almost 5 years ago

+1 It would really speed up our ticket creation.

#22 Updated by Yuu YAMASHITA almost 5 years ago

+1

#23 Updated by Yuu YAMASHITA almost 5 years ago

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

#24 Updated by Deoren Moor over 4 years ago

+1

#25 Updated by K. F. over 4 years ago

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

#26 Updated by Dipan Mehta over 4 years ago

+1. This is necessary.

#27 Updated by Stefan Tatschner almost 4 years ago

+1

#28 Updated by Eugene B almost 4 years ago

+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.

#29 Updated by Vaclav Tůma almost 4 years ago

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 ?

#30 Updated by Toshi MARUYAMA almost 4 years ago

  • Related to Feature #4244: Multiple email addresses for each user added

#31 Updated by Stephane Lapie about 3 years ago

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) :

--- 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.

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

#32 Updated by Akipii Oga about 3 years ago

+1

#33 Updated by Alexander Strunck almost 3 years ago

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.

#34 Updated by Martin G over 2 years ago

+1

#35 Updated by Benjamin Baumann over 2 years ago

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.

#36 Updated by Inese Ez over 2 years ago

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).

#37 Updated by Enderson Maia about 2 years ago

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

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

#38 Updated by Petr Mlčoch about 2 years ago

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]]

#39 Updated by Go MAEDA 11 months ago

  • Duplicated by Feature #24943: Issue watchers to have groups in addition to users added

#40 Updated by Stephane Lapie 6 months ago

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...

#41 Updated by Andreas Deininger 5 months ago

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?

#42 Updated by Stephane Lapie 5 months ago

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.

#44 Updated by László Bokodi 5 months ago

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.

#45 Updated by Stephane Lapie 5 months ago

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

I just integrated it.

Thanks!

#46 Updated by Andreas Deininger 4 months ago

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.

Also available in: Atom PDF