View Issue Details

IDProjectCategoryView StatusLast Update
0004782mantisbtfeaturepublic2010-09-17 06:57
ReporterMattB Assigned Tothraxisp  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionduplicate 
Summary0004782: Ability to assign bugs to groups rather tha individuals
Description

It would be really useful to be able to assign a bug to a group of people.

For example, in our organisation we have 3 developers working on a project. If an issue is reported, the reporters doesn't always know who to log it to, and the person he or she chooses may be unavailable at that time so the other developers don't receive e-mail notification.

If the reporter could assign it to "developers", Mantis could send an e-mail to all three developers and an individual developer could then assign it to himself (or someone else) as necessary.

The "developers" group here doesn't necessarily relate to the user permissions in mantis - for example, bugs to be assigned to "frontend developers", "backend developers", "graphic designers" etc.

TagsNo tags attached.

Relationships

duplicate of 0005081 acknowledged Assigning multiple persons to an issue 

Activities

vboctor

vboctor

2004-10-26 17:11

manager   ~0008178

The way to do this is the following:

  1. Create a forwarding address "developers@example.com" on your domain. This should forward to the three developers.
  2. Add the user "developers" to Mantis with access right "developer".
  3. Now issue can be assigned to this user and email notifications will be sent to all developers.

The only problem here is that when you search for unassigned issues, "developers" are considered assigned. But this is ok, because it is assigned to the team.

MattB

MattB

2004-10-27 02:57

reporter   ~0008181

I appreciate there are workarounds but they lead to other problems. Each project can have a different set of developers, in which case you would have to create e-mail groups for each project. For larger organisations this can be a maintenance nightmare as you would have to keep updating these groups all the time.

Fair enough, you would have to do the same if Mantis supported groups but it makes more sense to deal with it all in one central place, ie Mantis. You could even add automatic support for groups (ie the developers group), thus eliminating group maintenance.

Matt_wc

Matt_wc

2004-12-15 20:13

reporter   ~0008645

This is an interesting feature request. I too would like to see this feature, but don't have my head around exactly how it would look & be implemented.

One way to think about this:
Have the ability to select multiple users per issue when assigning them (requires another table?), and when viewing the issue have something like:
User1 | User2 | User3

This way when searching for issues assigned to a particular user, all of them come up.

Thoughts?

MattB

MattB

2004-12-16 07:42

reporter   ~0008654

Admittedly I haven't thought through the entire system but the chief reason for this is lack of knowledge from a reporters point of view. ie a tech support reporter may not know which developers work on project X and which of those developers deal with (for example) a reporting tool in the project X.

So the reporter will just assign the bug to the developers group in project X (could have the groups listed in the "assign to" dropdown enclosed in square brackets or something). Each developer for project X wil lthen be notified and someone can take it upon themselves to assign it to themselves or the correct person.

It also helps the system if a certain developer is not available - ie if developer Z is on vacation and the reporter assigns it direct to developer Z, none of the other developers will really be aware of it until Z comes back and either works on the issue or re-assigns it to someone.

thraxisp

thraxisp

2005-01-09 09:14

reporter   ~0008898

Duplicate of 5081 since someone sponsored that one.

Issue History

Date Modified Username Field Change
2004-10-26 13:02 MattB New Issue
2004-10-26 17:11 vboctor Note Added: 0008178
2004-10-27 02:57 MattB Note Added: 0008181
2004-12-15 20:13 Matt_wc Note Added: 0008645
2004-12-16 07:42 MattB Note Added: 0008654
2005-01-09 09:14 thraxisp Relationship added duplicate of 0005081
2005-01-09 09:14 thraxisp Duplicate ID 0 => 5081
2005-01-09 09:14 thraxisp Status new => resolved
2005-01-09 09:14 thraxisp Resolution open => duplicate
2005-01-09 09:14 thraxisp Assigned To => thraxisp
2005-01-09 09:14 thraxisp Note Added: 0008898
2005-04-18 10:32 vboctor Status resolved => closed