|
I'm voting for this one. I expected that every user name in a group with the Assignable User permission would appear in all "assignee" drop-down lists throughout the application. Instead, components and projects have only "Project Lead" (which should be "Project Leader") or "Default" or "Unassigned."
See linked Issue for explaination of Component Leads and default assignment of Issues.
Thank you Owen, but it does not answer to our need.
We don't want to use components in every project, because this notion is not really understandable for non IT users. In addition, we would like to have a different person as the default assignee than the project or component lead. Then, we should be able to define precisely who is the default assignee for a project or a component : we should be able to select someone (a role or a user) in the list corresponding to the Assignable users of the permission scheme --> you just have to get the "assignable" value and allow the admin to select in between the different elements it contains. Richard,
The 'component lead' or 'project lead' are only used in JIRA for the default assignees. Why can you not use them? I'm not sure if I'm missing something? Your original query seems answered by Jeff's comment above? Perhaps you can expand on your original request. No, the Project Lead is used also as a role across the schemes...
We should have another role : default assignee... So you are using the Project Lead in the permission schemes?
Ok - now I get it. Yes, we use the project lead in permission scheme to administrate the project and the issues of the project, and we want that the default assignee is linked to a generic mail box. We cannot manage that today, because the default assignee and the project lead are the same role.
Same here. We like to assign lots of permissions to the Project Lead, but use a different person to perform "JIRA triage" and make the first assignments.
Really would like this. One problem is that your user-interface hints that you can have a different "default assignee" than the Project Lead. Then you dig around- In 3.2 you will at least be able to set the assignee in a workflow post-function on the initial 'create issue' action, either using the built-in UpdateIssueFieldFunction or a custom function implementing whatever rules you want. This should be possible in 3.1.1 too, but (at least on my box) it breaks:
Caused by: java.lang.NullPointerException I am evaluating 3.1.1 Enterprise Edition version of the JIRA and faced the problem of the Default Assignee field myself.
Although I am happy to see that it is going to be fixed in the next version I do not agree with the approach Atlassian is planning to use. I am quite sure that this field (Default Assignee) should be set with a single drob-down menu and not with editing the workflow. The reason is quite simple it is much much more complicated to edit the workflow than to set a simple dropdown menu. So please insert the dropdown solution besides the workflow editing option. I am also voting on this.
In our organization, with large projects, where there are many bugs added everyday, the team lead does not have time to assign these, and shouldn't be using their time to do this, particularly if a large number of bugs are often irrelevant. Typically the default assignee role goes to the quality engineer for that project who then analyzes it and dispatches it to the right person as required. I'll echo Michelle's comments. This is true in my organization, too.
Keep in mind that, while Jira may not put any other meaning on the Project Lean than as a synonym for "default assignee," anyone using Jira is going to put a different meaning on the term. Most importantly, the role of administering the project (creating new components, versions, etc.) is distinctly different from the role of "default assignee," who must sort through new tickets and assign them where they belong. Also, it's challenging in a large organization to enter someone into a system as "Project Lead" when they aren't, in fact, the project leader. Just changing this from a bug to a feature request, so that it will get handled by the right people
We leave bugs for triage Unassigned; our triage filter looks for bugs assigned to Unassigned.
We are like other people that has someone assigned to do the first pass through the tickets and then assigns them as needed. Please add this feature for people that want to use the product as a help desk system!!! It can't be that difficult to implement either. Thanks.
We wish to use a mailing list as default assignee; the individual in that list who decides to pick up the item then self-assigns. Please consider this variant if anything is done.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Perhaps what you need are arbitrary fields on the Project object, to store project metadata? For that see JRA-1991