|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Anders Hovmöller - 14/Mar/03 10:07 AM
This is very important for us too.
I am currently evaluating issue tracking systems, and this is a key feature, since nearly everything we do is interdisciplinary team based. (You get a sales guy and an engineer and a QA droid working the issue together, then hand it off to manufacturing and marketing for implementation and release.)
Managers for each department need to know the issue loading for their people (and themselves - they'll be in the system too). And it needs to be tracked and updated continually. We'll be using the system to track R&D projects (ideas while they are small, until they become "products" and get their own management structure), customer support, field service, manufacturing support, vendor issues, contractor issues, continuing engineering, etc. Basically, we need to track everything an under-staffed engineering department needs to get done. The system must also support bouncing ownership of an issue between informal teams, so engineering might only be involved at the beginning and end, and the money folks would be in the middle. Having multiple assignees is the first step toward the capability we need. We also have a need to associate multiple people with an issue, although our preferred model would be a little more complex. What we would like to be able to do is to assign people with different roles to an issue, eg. Original Reporter (sometimes different from Reporter), Developer, Architect, Tester. The role of each is different and would involve certain tasks as various points in the issue workflow. For instance, the developer may need to propose a solution with review by the architect, and the tester needs to verify the fix before the issue can be closed. Utimately it would be great if this could tie in with an issue type specific workflow (so that User Stories could have more heavy workflow than a Bug for instance).
This could be fairly simply achieved by having a list of users with definable roles, separate to the Assigned user (who is ultimately responsible for the issue). There have been some concerns on the mailing list whether implementing this feature would block the implementation of other features later.
http://forums.atlassian.com/thread.jspa?forumID=46&threadID=3447&messageID=80494719#80494719 The main point is that it would be impossible to determine the remaining work per developer, which is a very useful info for team management. I definitely agree that it is a disappointment that this would be an Enterprise only feature, when it applies to all uses of JIRA that I have so far come across. I have over 10 projects using JIRA, and all of them could use this.
I'd also like to see Atlassian reconsider their decision to place this as an Enterprise feature instead of Normal. Ben I too would really like to see this in the pro version, both for personal reasons (that's what we've purchased and my company does not need any of the other features of the enterprise version) and for conceptual reasons.
I believe this kind of a change is an essential change to the conceptual model of JIRA that better reflects how most organizations actually operate. No matter how large or small an organization is, if they need an issue management system bad enough to spend $1000 on it, they will have multiple people working on the same issue at the same time. It is the exception that one person completes all the work for an issue, and a workaround to either perform work in sequence or to create other associated issues for each individuals effort. Just my $0.02. Thanks for the opportunity to comment. It seems to me that having multiple resources for an issue would be very useful when you implement a more complex workflow. If you had a work flow with both a development and a QA phase then you'd want the Development resource assigned to the development phase and the QA resource assigned to the QA phase.
As to being able to handle the managment issues, if you supported the multiple resources with a representative workflow, then it should be a relatively "simple" matter to extend the management features to take into account the multiple roles. And I suspect that handling a group of people in a single role (actually have 4 developers) as an aggregate should be sufficient. I would also like to be able to assign an issue to a group of people and allow one of the people in that group to take ownership. Our company also needs the ability to assign multiple people to an issue and I can't see us buying the Enterprise version either (we don't need most of its features). Chalk up another vote for this feature (yes, I voted!) to go into Pro from us.
here's my vote for this feature, please only count it if implemented for professional version...
How is the status of this feature?
Is this functionality released in the new Jira 3.0 version? I think that it can now be done using sub-tasks since 3.0 of JIRA !
Yes, as each sub-task can be assigned to a different assignee, using sub-tasks is definitely an option.
I also have the need to assign an issue to a group. In my case it's the "Content" department. I don't care who fixes it - any member of the group can. Sub-tasks don't help.
I'd like to add that our old bug tracker allowed assignment to multiple people and it turned out to be a really bad idea. We would find bugs with 5 developers assigned and none of them working on it, because each of them thought that one of the other four was. One of the reasons we chose JIRA was because it elminated this problem.
So I understand that other organizations may want this feature, but if you build it, please give us a preference so that we can turn it off. Thanks. I do see that we might want a slot to record the business-owner in addition to developer, but editable reporters should solve that problem. I also strongly request that this be able to be enabled or disabled per project.
This makes sense for some cases, but really doesn't make sense for other scenerios. We prefer to change owners of tickets as they move through the workflow-- it's just human nature for people to refer to the tickets that they "own," and be less concerned with the other tickets. It would be cool if someone who was previously an owner automatically became a watcher, as the ticket moves through the process. It would also be useful to have the work log split among the different people/roles and then be able to query a sum based on groups; then, for a group of issues, you can get how much time was involved by each role
Folks,
In the latest version of JIRA (3.4), it's now possible to add a custom field for multiple users. Thus you could add a custom field called "QA Team", which has the users involved in the QA process of this issue. Moreover, notification schemes can also be based on this field. This will keep the system simple for most standard installation (there can be a pretty strong case for issues having one responsible "Assignee" even if there is a project team) and let people customize for more complex cases through Custom Fields. Thoughts? Cheers, Mark C This solution with custom field is not good for us.
The assignation has really a sens in JIRA and cannot be replaced by a field. We really need to assign an issue to a group (Several people of the same service). The sub-Task, for us, has an another interest : if issues relate to several services. This 2 functionalities (assignment to a group and sub-tasks) can be used at the same time. Actually, we have implemented the suggestion made by Mark (http://jira.atlassian.com/browse/JRA-1397#action_48372
 ), which is quite enough except for the fact that logging work should be splitYours I, too, would like to see this implemented. It's really two features for which I'm looking. The ability to assign an issue to a group, and the ability to assign an issue to multiple users. Both have applicability in my workflows.
Of the two, the ability to assign an issue to a group is the most critical... The ability to assign more then one person to an issue is very important and should be followed through with the ability to create Estimated time(work) per assigned person. When/if time tracking the people add the actulas and change the remaining the values should be aggregated up into the issue level of the record.
Example) Yes! This is a very important feature I need as well!!
I need to be able to do work estimates, and then time tracking... – – Bill Van Emburg This issue seems basically 'done' with the release of 3.6, where one can have an 'Assigned Group(s)' group picker custom field:
This group picker custom field can be specified in both permission and notification schemes. For example, this allows the list of assignable users to be restricted to the group:
and that group would get email notifications. If you want to restrict the groups in the 'Assigned Group(s)' drop-down, make it a select-list whose values are group names. As for reporting, regular JIRA statistics (eg. issues per group) and charts As for time tracking, there is an already-popular issue requesting that time estimates for subtasks be aggregated to their parent task: http://jira.atlassian.com/browse/JRA-3009 If this were implemented, then a task with two "assignees" could be broken into two subtasks each with their own assignee, work estimate and work log. The work estimates would be shown on the parent issue. Could people requesting this feature have a go at using 3.6's group picker enhancements, and see if a solution based on them meets all their needs? After creating the group picker, I can get it to show up on the "Create Issue" page and the "Resolve Issue" page. But where can you change the group on the issue itself?
I selected for it to show on the "Workflow Screen" but do not see it appearing on the issue page. Am I overlooking it? We need the ability to assign to a group and then change the group on the issue itself. Hi,
The field will show up on the VIew Issue page, only if it has a value. It also depends on how you have arranged your screens. If you are having trouble displaying the custom field please contact our support team - http://support.atlassian.com Thanks, I agree with C Moore. It would be nice to be able to select a "Group" from the "Assign-to" drop-down in addition to normally jira users. The current implementation of "Group Picker" works well for searching using the Issue Navigator or on the Permissions and Notifications Scheme however being able to assign multiple users to an issue at one time would definitely be a great option.
I agree with C Moore and Ben Jones. It would be much better to be able select a group from Assign to -dropdown. This is an important feature in team work. I hope you fix this for the next Jira release.
We'd love this feature. We are trying to move from Peoplesoft Helpdesk to Jira and so need this feature. Help us move from PS plllllease
 Yes, it would be great if there were the possibility to notify some selectable peoples if a issue in a special component is created ...
[
Permlink
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
Assign issues to multiple users or a group
