Can I change my Default Assignee to be someone other than the Project Lead?

[Jacqy George]

When setting up a Project in JIRA, the default assignee is always the Project Lead. Is there a way to change this on a project by project level basis?

Alternatively, could you have 2 project leads defined?

[Ken Jessen]

Why on earth would you enforce the restriction that the default issue ID can only be the project lead or nobody??? This makes no sense to me.

Is there some security issue I'm not aware of?

[W H]

It is standard project managment. Each issue ultimately has only one owner. If is has more than one, then it really has none because it creates the "I though he/she was working on it" situation. And for the user reporting it, they know who their contact is. You can send an issue to multiple people via notifications. You can make sure they can all work the issue via permissions. One name will remain in the default assignee though.

[Vidal Abad]

Each issue should have one owner (although in some cases i think a team owner works better), but why would I want all issues to go to the same default owner.

There are different issue types, each with their own workflow and screens. Why is there only one default assignee to rule them all?

There may also be users that in fact do NOT know their contact. With the introduction of JIRA service desk the reporter will know even less. However, in JIRA service desk you can choose [to force] the assignee, but you eliminate the option of choosing one.

[Vidal Abad]

and what about companies that use the term "project" losely. and use one "project" for it's tech support or "service desk". You really want to have the PM delegate 100+ issue tickets daily?

[W H]

Again, single contact. One person is ultimately responsible for that Jira project (Project Managment!) so that one person gets the issues and can delegate from there. Think of project management scenarios when you have a project with multiple project managers (which is not very often might I point out) you still have one individual who is the primary project manager and ultimately the responsible contact. Same idea applies here. The name in the default assignee field really means little if you have your permissions and notifications setup correctly, from an issue resolution standpoint. I get notifications and work on issues in Jira that I am not the default assignee on just fine.

[W H]

Well if you are using a tool that's modeled after project management "best practices" but not actually following those "best practices" then situations like that will arise. If you want to be rogue and loosey-goosey, then it's up to you to figure out the curveballs. If you have "100+ issue tickets daily" either you have a single project that is a nightmare, or you have seperate projects. And if you have seperate projects, create seperate service desks within them. Easy. Again, the default assignee is just a name...notifications and everything else can go to a group and individuals within that group can change themselves to the assignee if they are working an issue. All it takes is some education and communication.

[Vidal Abad]

afaik JIRA was created as a bug tracking tool first and foremost. Project magagement were added later.

service desk functuionality was added later as well. if you don't get 100+ calls a day to your tech support, you are probably a 1 person IT shop and default (and only) assignee would be you.

[W H]

And SharePoint was created as a intranet portal project and now major internet websites run it. Products and their functionality and purpose change. But you are missing my point. You said what if an organization uses project loosely (first mistake) and puts everything under one project. I'm saying that's a bad idea. If they were seperate and a single project is getting 100+ issue, it is a nightmare project. Help desk/Service desk calls are not part of the project. They are support issues. And even so, if you are taking support calls, um, why can't the person taking the call and creating the issue change the assignee? And since you asked, we get well over 100+ (1000+ calls and emails) service desk issues a day. We have a single default assignee for the automated ones, but notifications go to multiple people who then can assign it to themselves if they are working on it.

[Vidal Abad]

I think you are missing my point as well. I'm just trying to illustrate a scenario where someon would want multiple default assignees. Personally I think the minimum should be being able to set default assignee based on the issue type.

I guess the moral of the story is if one chooses to work outside the utopia of best prectices there is no hope for support.

PS - if you get over 1000+ service calls i guess you aren;t using JIRA to rack them as by your own admission that would be a "nightmare project".

[W H]

The first part you can do with default handlers if the issue come in via email (and you have seperate projects!)

Yes, if you chose to do something outside of what is normally supported, your support options will be lacking. That's common sense. Chose to modify your car, your warranty options diminish. Companies cannot, and should not be expected to, support everyone who decides they are going off on their own.

P.S. You missed the part where I said a service desk or support call is not a project. Because, well, it's not a project. It is a support call. The call itself can be about a project, but the call or help desk itself is not a "project." I think you might need to go figure out what that term really means, instead of using it "loosely." And of those calls and emails, probably 90-95% of them are regular user issue (forgot password, locked out account, how do I do this questions, etc.) which aren't project issues. So yes they are tracked in Jira, they go to a single default assignee, but notifications go to multiple individuals and our users are informed enough to take those issues and assign them to themselves or someone else as needed. It really isn't difficult. Default assignee is still just a field. It isn't some magic holy grail that it is being made out to be in this thread.

[Lewis Jardine]

Wann, TBH I am totally with Ken here, there is no reason that in a real project the project lead would be the issue screening person. Whilst I am comfortable with the single owner it is clear that there is either a technical restriction or this is just a poor implementation by JIRA.

[W H]

No reason in a real project? Is there a fake project? What? Anyways, they don't have to be the issue screening person. It is simply the default assignee. In a "real" project, this is normally the project manager. But I use a dummy account for this actually. You can change and route issue with workflow, or if you get them by email, by mail handlers. Which is what I do, which is why I use a dummy account as the lead.

[Marco Härtel]

My main pain in the ass is the following: I want the Assignee field to be mandatory while my users create an issue. But making "Assignee" mandatory is only possible when the default is NOT unassigned. which means it needs to be the Project Lead. This leads to an automatic Assignee of the Project Lead. But. What I want is that the user who is raising the ticket MUST fill in a name in the Assignee box. Better a wrong assigned Issue than an unassigned or all assigned to my ProjectLeads. Why is there no possibility to make that field mandory but blank like it is e.g. with "Summary"?

[Paul Thomas]

"And SharePoint was created as an intranet portal project and now major internet websites run it. Products and their functionality and purpose change." Agreed. And given that JIRA actively tries to sell itself to helpdesks, it should be attempting to support how helpdesks are run. It also sells itself as "the" Agile management tool. A core concept of Agile is that teams are trusted and don't need the strict hierarchical management that you are talking about. Even if your "best practice" is the only "best practice" (it isn't, you should be more open-minded), adding an option alongside project lead for "current user" is a null change for you. Everything you want to do and enforce is still possible, and people who want to use a different best practice which JIRA claims to fundamentally support can have their way of doing things.

[René Mulder]

Add a post-action to the create transition in the workflow assigned to your project. This post-action then assigns the issue to whomever you want.

[kim delgadillo]

nice solution thanks (but still a workaround)

[Jobin Kuruvilla [Adaptavist]]

No, you can only configure it as project lead or unassigned. The only exception is component leads which can be individuals other than project lead.

Issues will be assigned to component lead if the component is selected during the issue creation.

[Jacqy George]

Can I make a Component be required upon ticket entry by default? I don't see that it is mandatory. I get my options and then an 'unknown'. I want a single component and require that it is selected to force the asignee. Possible?

[Jobin Kuruvilla [Adaptavist]]

Yes, you specify it under field configurations.

[Marc]

Hello Jobin,

And what happens if more than one component is selected, and each of these components has a different lead?

Who will be the assignee?

Thanks in advance for your help!

Marc

[Jobin Kuruvilla [Adaptavist]]

If an issue has multiple components, and the default assignees of components clash, the assignee will be set to the default assignee of the component that is first alphabetically.

See https://confluence.atlassian.com/display/JIRA/Defining+a+Component#DefiningaComponent-default_assignee

[CTW]

The post-function can only "Assign to Current User", "Assign to Project/Component Team Leader" or "Assign to Reporter". I hoped to assign all issues to our "Screening Officer" to formally approve, before allowing them to progress to the selected Component Lead.

[Vidal Abad]

You can do a post function that updates a field. For the field, choose "Assignee" and set the value to "Screening officer" in your case.