View Issue Details

IDProjectCategoryView StatusLast Update
0005081mantisbtfeaturepublic2020-10-26 12:27
Reportergodziu Assigned To 
Status acknowledgedResolutionopen 
Product Version0.19.2 
Summary0005081: Assigning multiple persons to an issue

many projects require multiple persons to be involved in solving an issue, where mantis allows only one person to be assigned.

this would be a huge advantage.

TagsNo tags attached.


related to 0010207 feedback Allow multiple valids emails address per account (patch attached) 
has duplicate 0004252 closedthraxisp Assigning an issue to more then one person 
has duplicate 0004782 closedthraxisp Ability to assign bugs to groups rather tha individuals 
has duplicate 0006727 closedthraxisp Direct a bug to several users. 
has duplicate 0007863 closedgiallu Allow an issue to be assigned to multiple developers 
has duplicate 0006530 closedgiallu Assign issue to several account 
has duplicate 0009499 closedgiallu assign problem to multiple users 
has duplicate 0010266 closedvboctor Assign bug to more users? 
has duplicate 0010885 closedgiallu Assign issues to more than one developers or a developper-group 
has duplicate 0017090 closedatrol Multiple assignments 
has duplicate 0020304 closedatrol Multiple user in same work profile 
has duplicate 0022592 closedatrol MANEJO DE UN GRUPO DE USUARIOS 
has duplicate 0025393 closedatrol Allow Reporters to Assign an issue to multiple Users at the same time. 
has duplicate 0027426 closeddregad Asignar varias personas a un error 
related to 0006644 closedgrangeway Patch for multiple developers per issue 
child of 0006470 closedvboctor Features for Mantis 2.0 




2005-01-07 09:42

reporter   ~0008890

Hmm, would a "user group" concept work here (i.e., assign an issue to one user group, which contains a group of users who are related in some way)? That might achieve the same results without impacting the ease of use of the package for those that don't need to assign issues to multiple users.



2005-01-09 07:24

reporter   ~0008896

well, not exactly. my teams are usually working with different person-configurations (in task 1 A works with B, but for task 2 a works with D). and since the teams are 7-10 persons, making a group for each configuration would be nonsense.



2005-01-17 06:11

reporter   ~0009044

hello... user GROUPS is not what i need. any comment on this one?



2005-01-17 10:11

reporter   ~0009047

Hmm, if user groups are not the answer here then 0004782 is not a duplicate of this issue.

If you want to be able to pick multiple assignees on a per-issue basis, this would probably require replacing the handler_id field in mantis_bug_table with an additional table containing user_id and bug_id values (like mantis_bug_monitor_table).

User groups would probably require a table containing a group name and user_id values.



2005-01-17 11:33

reporter   ~0009048

i really like this idea and would like to see both, multiple user assigements and the possibilty to create groups and then assign the group to the issue and everyone in the group have the issue in his assigement list



2005-01-27 10:42

reporter   ~0009119

may any news from the responsible persons?



2005-01-31 06:29

reporter   ~0009150

any news? team mantis - hello? :)

this feature is of substantial value to me and i think i am not the only one.



2005-01-31 07:28

manager   ~0009151

Implementing this feature requires a significant amount of effort. This is due to the fact that Mantis source assumes that there is always one handler for an issue. This is the case in the GUI, filters, view issues, print issues, csv export, email notifications, access rights, ...etc.

The other issue is that having multiple responsible persons may make Mantis more complicated or slower for people who do not need the feature.

I have been thinking of a compromise that doesn't involve a lot of work and also that partially achieves what you want to do. I couldn't find a reasonable one. The only thing that you can now do, is to have custom fields that are automatically populated by the developers list. In this case you can have multiple people on the issue, however, have the current person that is actively working on the issue as the current handler.

The other option is to create child tasks from the current task and assign each child task to a developer. This is assuming that the work to be done by each person is clear and can be documented in a child issue.

Looking forward for your comments.



2005-02-01 07:55

reporter   ~0009162

i'm not saying it is easy, i am only saying this is important.

imagine quite a big project, where we have horizontal responsibilities. in my team i most often have let's ssay 3 developers working on a feature: 1 on GUI, 1 on business logic and 1 in DB. i get a change request from the customer and all i know is that it is feature X. now what i need to do is assign all of them to this change request, because i have scant idea where the change will be (GUI, business logic, DB).

assigning groups won't help, because they are NOT STATIC! they are dynamic, even during a couple of day period and i have a number of developers.

creating subtasks won't help because only the developers know who will actually make a change within the small feature-team.

additional fields won't help because in this case i would have the main handler (assigned one) and the supporting ones (those in additional fields). and what about all the features like email notofications etc.?




2005-02-01 08:45

reporter   ~0009163

i know its many work, but i have nothing to add, godziu told all the important things, and also my thoughts about this topic.....its really needed i guess



2005-02-14 18:09

reporter   ~0009311

any progress on this topic? It would really help to work witb BT



2005-02-14 19:52

reporter   ~0009313


Just some of my thoughts (as I've worked on development teams, managed them, and now am a Senior Management Consultant at one of the 'Big 4').

Because you have such dynamic teams, try some non-technical solutions from an organisational behaviour standpoint.

Try this:
Instead of focusing on the need to change Mantis by allowing multiple owners, simply assign one of the developers as the change leader (CL). This temporary role of the CL can be as simple as managing the flow of information. Example, you get a change request from the customer for Feature XYZ. That feature's CL is Mary Jane. By giving her the information, she is tasked with sharing it with her dynamic team. (i.e. posting it on mantis)

This technique has alot of positives:

  • easier and faster as you deal directly with the person
  • dev team is aware when changes are added, as they speak with the CL
  • gives developers who want more responsibility the opportunity to do so
  • allow for more communication with your entire development team
  • develops collaboration and delegation for you and the team

Outline the role very clearly.
. What does it do?
. What does it NOT do?
. How long am I a CL?
. What if I do/don't want to be a CL?

Yea, I know it's work. But the payoff will be worth it (see above). If you are only looking at $$ results, think how much time you will save by delegating - then apply your salary, sales potential, customer relationship building opportunities to this additional free time.

Remember that in small teams, technical answers to communication and management challenges are rarely the best.

P.S. If you use this, make sure you do proper and open feedback from your staff as the best of intentions may not be enough to overcome abrasive communication.

Long winded I know, but I hope it helps.



2005-02-15 03:09

reporter   ~0009318

Last edited: 2005-02-15 03:22

Thoughts on usergroups:

  • useful feature. I myself would like to assign a bug to a whole department and let them fight about who picks it up.

  • If usergroups are introduced, they should be presented and be selectable as users currently are; perhaps bracketed to indicate it's a group. You could then assign a bug to an individual, or to an entire department.

  • There must of course be a who-belongs-to-which-group manager page.

  • As for Godziu's dynamic environment: I'm not sure the environment you describe is a situation you would want everywhere. How are the roles defined in such a project?
    My biggest fear is that it is not at all clear who to approach about the bug. Everybody in the group can end up thinking 'the other guy' will handle it. In all environments I worked in, there is always someone with an overview of the whole thing, even if there are multiple people working on it at the same time.

Suggestion (godziu, how about this?): ability to assign one master-handler to a bug who is the actual team-leader for this one; and assign several sub-handlers who get emails about it. The teamleader is the one responsible, even if he deligates work to others.

Perhaps (for the time being) you could use the Monitor function for this. Convention in your project would be that the teamleader sends a couple of reminders to the other developers so they're automatically set as monitors. Montiors would be handlers to the bug.
In addition to this, why not create several children for the bug and distribute them over the team?

I didn't care much for the workaround with email-groups; not very elegant to solve a mantis shortcoming in the mailer.



2005-02-17 19:09

reporter   ~0009332

added again + 5 $ to sponsorship, cause i still think the initial request is the only "clean and effectiv" solution.

"ability to assign multiple persons to a bug, and groups"



2005-02-21 17:50

reporter   ~0009357

thank you guys for solutions and suggestions.

as for the Change Leader, it is my Lead Developer who owns the change actually. he/she assigns the change to whoever is needed (HERE is the problem) and he/she verifies the solution (of chooses a "verifier").

as for monitoring: guys, a change may be a 2 hours of work issue. there is no time for monitoring and part-time solutions.

a CLEAN solution is needed.

mantis team: HELP! :)



2005-03-07 05:53

reporter   ~0009489

hello team mantis...

any plans concerning this feature? :)



2005-03-07 15:20

reporter   ~0009495

Godziu, if you assign the same issue to 3 persons... who decide when the issue is resolved ?

I believe in using child task for each, even if there is nothing to do for one of them... each developer resolve his own task (even saying there was nothing to do for him) and when all tasks are resolved, so the mother task can be solved.

I don't believe in a working solution with the same task affected to more than one person.



2005-03-09 02:57

reporter   ~0009501

We are using a "workaround":

One person is responsible for the problem! Other developers are involved by monitoring a problem. This can be done very easy by sending a reminder to the develloper (This is a default feature which can be switched of in the config_inc.php!)

On the other side every one can add notes to a bug (like me in this case).



2005-03-09 16:47

reporter   ~0009504

guys... we are going in circles...

1) if a task is assigned to 3 persons, the person who decides it is his/her bug resolves it; I have project oriented, responsible developers - they know they have to correct bugs; as a backup - I have the lead developer or someone similar - but we want to MINIMIZE his/her role

2) one person responsible for the problem: guys, I need a mechanizm for choosing such a person! at the beginning we don't know who the person is.



2005-03-10 00:42

reporter   ~0009505

Another option.

You can create a task (not affected) and use reminder to "build" the team.

When a developper of the team find there's an impact, he creates a child of the first task. Thisk child issue is affected to him.

When all of the child issues are resolved, the mother can be set resolved.



2005-03-11 06:51

manager   ~0009513

I have no plans to implement this as part of the standard Mantis, at least for the moment. I think some of the users who commented on the issue also agree that this is not a typical case. I would say that support for groups and assigning an issue to a group will eventually be added to Mantis. However, as you made it clear, this won't satisfy your requirement.

Sorry for that.



2005-03-27 15:32

reporter   ~0009666

Hi all!
I also have sometimes the requirement to assign ONE report to more than one developer, because it effects e.g. database and GUI to fix the problem.
I also have thought about this problem. But with this version 0.19.2 I have a good idea as a workaround (of course, not always working!):
report the problem, assign it and clone the report. Assign report 2 to developer Nr. 2 and reference the reports on each other. While this feature is becomming useful, I think, this would help. What do you think?



2005-03-30 02:27

reporter   ~0009682

Reminder sent to: steffi

Hi Steffi,

I think cloning is not a good idea because one strengh of mantis is to keep all information centralized (per case). Now you have to check all copys for changes...



2005-05-11 12:33

reporter   ~0010089

When you clone an issue, it is still linked back to the original. Keeping a master = parent and clone = child relationship will add a message when you try to resolve the parent without resolving the children.



2005-08-08 20:50

reporter   ~0011126

My sponsorship is actually for user groups, not multiple-users. I agree with gtomlin's suggestion that 0004782 is not really a duplicate of this, but the discussion has clearly moved here so I am going along with that.

My users discovered Reminders and Monitoring on their own and this works fairly well for us as a solution to the dynamic-multiple-assignee problem, when we need it.

One thing I would do with user groups is auto-assign new issues to a group of reviewers and have them all share the workload, then turn things over to a group of workers and have them also share the load. Ideally it would not force the status to 'assigned' unless the assignee is a single person, so I do not have every issue showing up purple.

There are also a lot of delegated administration features I would like to have that require a group concept first. I have tried to simulate some of these by creating subprojects to match the groups I had in mind, but that is a poor fit.



2005-08-11 12:29

reporter   ~0011174

Hi all,

Been watching this discussion, and I posted the original request for user groups (0004782)

I've worked on a small patch that doesn't solve the exact issue but allows the reporter of a bug to add users as monitors whilst the issue is being created. Those users are e-mailed when the bug is submitted.

Check out: 0006128



2005-08-12 12:53

reporter   ~0011194

Sorry I can't understand an issue.
Assigning that is when person - one person work on issue.

If an issue is BIIIiiiG need to make child issues and make a task as you are project manager.

And assigner of parent issue is responsible for fixing.

When there are many assigner, no one responsible. And as result no one feel it's pressure of a bug.

As a summury try to use child issues, for fixing subcomponents. Must be one person who responsible - ASSIGNER of the issue.

No? Explain me.

As a feature make chekbox for parent issue "notificate when child change". Almost as says MattB.



2005-08-12 13:01

reporter   ~0011195

I never see "Big" issues that fixed only by wide enough team.

For fixing such issue need a component method for it.
Try also child-clones.

That way you will see when each person make its part for fixing THE ISSUE.



2005-08-15 03:39

reporter   ~0011211

Three observations (mainly to Godziu):

1) For the majority of projects, a bug is the responsibility of a single person. He or she can use other resources or transfer the responsibility. In most projects, the responsibility is not shared. As was said before: If many people are responsible, no-one feels responsible. This really is a well-proven way: it is the way most projects work.

2) Implications, implications. The change you request looks small and innocent enough, but I fear it may have MAJOR implications on the way Mantis behaves. If this would be implemented, there will be a very large list of exceptions where a bug's status is changed to another state in some cases, but not in others.
Take Toddpw's note on usergroups. He would like the status of a bug to go to 'assigned' UNLESS the bug is assigned to a single user. This 'unless' raises hairs in the back of my neck.
This request is just the tip of the iceberg. The entire behaviour and workflow would be affected.

3) An impact-analysis of this change has never been made. You will find that even a small impact-analysis raises a whole batch of questions about how Mantis should behave if some users agree on something, but others don't.



2005-08-15 05:04

reporter   ~0011212

I read again all of it. Draw drafts of all problems. And can't understand needs in this issue.
If you don't enough category field use custom fields with "multiple listbox" and make in it needed groups and users.
Filters of mantis enough to make it usefull.

Imagine next situation:

  1. Some one make an issue.
  2. You assign it to "some peoples"
  3. Everyone thinks that it is not his, but his neibor have to fix it. Like this every one.
    So the question:
    Will someone of developers do "Assign to me"???
    I think no and you will have an issue hat will never be resolved.

Let's imagine another situation:

  1. Some one make an issue.
  2. You assign it to the developer. Ex: Alexandr.
  3. Alexandr see that this is not his bug, but bug of Ivan.
  4. Alexandr assign to Ivan.
  5. Policy of BugTracking - no issues open issue on developer.
  6. Ivan go to you and don't understand why Alexand assign to him.
  7. Short discussion resolve problem.
    This situation is larger but it is realy resolve problem who MUST resolve the bug.

The first situation is an example when manager don't what to look into bugs and think that developers will resolve it by himself.

The Managers (or CL - change leader) that not dive into bug. I call and will call bad managers. (If project is big I say about lover manager or project manager. defenition depend).

So the conclusion is.

  1. If you need groups or multiple assignig. You base on that small groups will assign to proper person itself. The fact is that no meter that small or large group will do this activity. If level of self organisation is high there is no difference.
  2. If you need and you have large dev team with large responsibility and not defined responsibilities. Try to use not only child issues. But use a subprojects.
    Scenario: testers (reporters) report to parent project. CL move issue to proper sub project. developers of subproject try to resolve it. The goal is tha all subproject have at least only resolved bug ideal closed. (why this is bad for multiple assigning and groups)

I alredy suggest in forum make for mantis templates of using exactly in manual.
Let's start do it.

P.S. See my previous posts for example if issue is really big.

!!!P.S. Can someone remove this discussion into forum?



2005-08-15 22:27

reporter   ~0011219

To mgerben: sorry for the confusion about my double negative. I said that I wanted the status to NOT be set to assigned unless the assignee was a single user.

Translation: I would like assigning to a group to leave the status alone, but assigning to a user to set it to assigned. However I recognize not everyone will want this so it probably needs to be configurable, just as it is already configurable (g_auto_set_status_to_assigned) whether the status is set.

I disagree with the assertion that only assigning something to a specific person convinces them to work on it. Assigning to a group really should mean that everyone in the group is expected to volunteer to work on issues, and when doing so they assign the issue specifically to themselves.

The whole point of this is to share the workload of reviewing new/feedback items, and dispatching acknowledged/confirmed items. I have a large number of volunteers who do not have a lot of spare time, so I am trying to make the most of the hours they do have in which they are motivated to work. Some of our people are assign-happy and this has often resulted in bugs sitting around being ignored by the person they were supposedly assigned to, because that person never agreed to do the work and doesn't feel obligated to do anything just because somebody thought they should be the one to work on it.

I have started training some people to look for red/yellow items and try to move those along, but without the extra association provided by some kind of assignment, this is more poll-itensive and thus people are less motivated because they have to check yet another website in addition to the forums and mailing lists they already check (or don't, as is often the case).

I can still make this work if assigning to the group slams the status field to assigned, but the coloring of the issue displays is far less useful.



2005-11-09 04:41

reporter   ~0011604

Last edited: 2005-11-09 04:42

Personally I agree that allowing a bug to be assigned to muliple users and to have group control would both be great features.

I thought I would suggest a work around for anyone who really needs this feature now, in case you hadn't already thought of it.

Create a new user "group1", with group1 encompassing users developerA and developerB. So that the developers get the email notification configure your email server to forward group1@ email to developerA@ and developerB@.

This should allow you to cover most of the facilities that you want, email notification to the team and the responsibility of the issue is assigned to the team as well.

Not the most elegant solution, but hopefully this should help some people wanting groups. Technically this can also be set up to cover all permutations of teams, so if you do not have set groups, but alternating groups specific to each task then you can set this up in the same way. Of course if you have a lot of developers then this can get very messy with a large number of email groups required.



2005-11-10 17:03

reporter   ~0011609

Last edited: 2005-11-10 17:07

1)Not wanting to stick my finger in the problem but already doing so....
godziu has a good point.
2) I'm a PHP developer, but right now I don't have enough time to get into mantis but I hope I will in the future.
3) The work around is to make a "group" of users for the category and not just a group period.
The group are going to be related to a topic or subject of which it matters to, so only administrator and managers would be able to do this and the users would be able to be assigned to more than 1 category.
And it also reduces the confusion on large number of tickets.
Wish I had time for this...



2005-12-02 10:19

reporter   ~0011682

Imagine this situation:

  1. Some one make an issue.
  2. You assign it to "some peoples"
  3. The one who first has some spare time or needs some time off from working on other projects or customers looks at the issue and fixes it.

It's working perfectly at our company. And I'd love to have that feature in Mantis as I'm trying to bring Mantis into our company and this is the most missed feature which is only party compensated by the "Allow multiple Viewers on Assignment"-Patch offered here...



2005-12-03 09:32

reporter   ~0011687

this will make mantis only miss a couple of features from peregrine and other top notch ticket reporting systems.



2006-01-27 07:52

reporter   ~0012027

I've coded a quick hack for this problem for 1.0.0RC5. You're free to try and comment, but please read the disclaimer :=)

The hack:



2006-01-28 00:44

reporter   ~0012032

Last edited: 2006-01-28 00:46

I just thought it interesting to note that Eventum has the ability to assign issues to multiple owners. This was actually one reason we did NOT CHOOSE Eventum. Mantis' notion of a single handler for an issue matches my organizations concept of ownership.

If Mantis does select to add such a feature, I hope it is done in a manner which includes the current, single owner behavior. I do like the observations others have made regarding parent/child issues.



2006-01-28 08:00

reporter   ~0012035

I agree with the Eventum comment.

I don't mind to assign a bug to one person who can then deligate it to someone else.
But I fear that when multiple persons own a bug, everybody will think 'the other guy' will solve it.

If everybody is responsible, nobody is accountable.



2006-01-28 08:57

reporter   ~0012037

I agree, that it is better not to have multiple people own an issue.

I could imagine, that there would be group support, so that I could pool the issues by needed skills. And then programmers could pick issues from the pool / group they belong to.

How would that be?



2006-01-28 11:20

reporter   ~0012038

Just to clarify: I didn't want to propose to let that become the only option for mantis, I just provided the patch so that other people who have the same needs as I did can use it. In our case, we only got about 5 developers working in a team. In this closed team, we've done good with not assigning the bug to specific people, but to all who have an idea about the topic of the bug.

If you read the forum entry, you'll see that this patch is not made in a way that it can be applied to the main mantis tree or anything..



2009-12-16 08:01

reporter   ~0023914

We've solved this by making 1 parent issue, clone the parent & add details - 1 for each person involved, and adding a relationship between the parent & children.

PARENT -> Assigned to: SELF (the reporter) OR to a project manager.
- CHILD1 -> Assigned to: Person1 - CHILD2 -> Assigned to: Person2
`- CHILD3 -> Assigned to: Person3

Each issue to be fixed is usually unique, and only ONE person should be ultimately responsible for fixing THAT issue. This is one of the GREAT things with Mantis. 2 colleagues/users/developers/whatever, cannot blame eachother for NOT fixing the issue, ergo; only ONE person is responsible.

When several 'smaller' issues (children) is part of one bigger issue (parent), either the reporter, a project manager or a senior developer checks that the child issues really are resolved; then being able to resolve the parent issue.

We don't have any "misunderstandings" anymore. ("A thought B fixed the problem in issue NNN - and vice versa", etc). Therefore, I suggest: 1 issue per person. Group them if necessary.



2010-09-03 09:23

reporter   ~0026567

In order to have something like this, I developed the tasks plugin which allows for assigning tasks to various other developers.
Plugin is available through this forum.



2010-09-14 00:53

reporter   ~0026708

Hi, I'm back using Mantis again after a few years of no one caring, we last used Mantis heavily in 2005 (v1.0.0rc1 !). I'm configuring 1.2.2 now and just donated $100 as I expect this to be a lifesaver since we have our yearly event coming up in about two months.

I like a lot of what's been done since 1.0 ... especially project inheritance which seems to be the one feature to rule them all now. In fact it's almost powerful enough to make user groups irrelevant. In fact I would say that a (sub)project with no categories defined or inherited is for all practical intents and purposes a user group.

This time around I am going to set up our Mantis install using project inheritance and composition so that all my desired user groups map to one of the (sub)projects. Then I can turn off auto-assignment status changes and use assignment to "" to indicate that something is on a shared queue and somebody in that (sub)project is supposed to claim it and work on it.

If this works out well, then I would consider my interest in this issue addressed.



2010-09-15 21:51

reporter   ~0026726

Apparently not. Users are not yet inheritable. Nice job on categories though.



2011-02-21 08:00

reporter   ~0028270

Last edited: 2011-02-21 08:01

The task plugin has been updated to allow automatic tasks to be allocated to various developers.
This fully covers this issue and even more. Other developers can be given specific tasks with specific deadlines.



2011-08-26 20:35

reporter   ~0029564

Hey All,

Do we have any updates on the development of this feature? If not, I might take a look at solving this, but it may require more then a plugin to address it.

Happy to help,



2011-08-28 19:42

developer   ~0029579

To my knowledge, noone in the team is currently working on this. If you feel like implementing this feature, please feel free to submit a pull request against the master branch on Github.



2011-08-30 13:37

reporter   ~0029599

Does anyone know the list of all of the scripts that call for the assigned user?



2011-08-31 04:33

developer   ~0029602

I'm sure your friend grep does ;)



2012-07-26 02:18

reporter   ~0032373

Well i've been recently working on a project, assigning multiple people. I've found nothing in forums, so i've started to change in codes and managed to do so!

Basically what i did was to cancel assign to button and instead of assign to, i just made one more "monitor list" and renamed to "assign users" and make lots of changes in code part. I managed it to work. If you are still having issues of assigning multiple people, i'd be happy to send my codes.

Have a nice day :)



2012-07-27 02:56

reporter   ~0032380

If you can combine all your changes into a plugin, it could be usefull.



2012-07-27 07:14

reporter   ~0032383

Well i'm kinda new to Mantis. Only been using for 3 weeks now. So i don't know how to make a plugin but i will look into it



2015-07-06 04:26

reporter   ~0051017

Can someone help me with this?
I can't find this plug-in. I prefer to use some plug-in to can upgrade core anytime.



2017-07-21 10:31

reporter   ~0057284

Hi, this issue is resolve? where can i find the plugin for mantisbt 2.3.1? Best regarts.



2018-09-27 05:12

reporter   ~0060698

do we have any workaround for that (patch - Plugin) or good news for implementation



2018-09-27 06:25

reporter   ~0060699

As far as i am aware, there is nothing new available. The Task module is still available also for version 2.x