Assigning issues based on components is fine if every issue type associated with a project has the same fields, screens, and everything. This is not a solution when you need wholly different issue types especially when you are organizing teams around individual projects as having multiple projects is unacceptable.

People have asked for this out of the box for years despite the "we think this is good enough" rubber stamp as there are good reasons for it. Keeping up this deafness to feedback is only going to create a desire for a new provider.

For project with a lot of components, it's a pita to change all components lead instead of changing the default assignee of the project. Forcing people to change the components lead isn't the greatest idea you could come up with.

We have decided to close this issue. Please refer to the statement in the issue description from 2012. We stand by it as of 31 March 2015.

Dave Meyer
Product Manager, JIRA Platform

The component work around has one flaw. I set up one component to be the default component for the project. Then, in the workflow I was hoping to set up a post function of create issue in the workflow. The component would be set to this default value when a user creates an issue and therefore the issue gets assigned to the component lead. Unfortunately, component is not included in the simple fields you can set in the post functions.

It is really strange that the only options are Unassigned or Project Lead. Please allow default assignee to be any Role in the project, or any specific User. This is a big limitation on project setup.

+ 1 for this, but given it was first reported 10 years ago I'm not holding my breath!

We would like to specify someone other than the Project Lead (Product Owner) to be the Default assignee.

We use the "Project Lead" as the key field in the filters for our agile boards, so I can't simply use this instead.

I'd like issues that move to "Ready for Estimating", "Ready for Dev" or "Ready for Testing" to be assigned to pseudo users that we have setup for each team (Team Earth). But since these teams share a workflow I can't hardcode it. And I don't want to have to start enforcing the use of components to achieve this.

It's these small usability enhancements that drive me crazy on a daily basis. I've logged, commented and voted on dozens and yet nothing ever seems to happen. Atlassian needs to start listening to it's users.

Sorry, but I can't understand why such a little effort development issue is now open since 2004.
It is obvious that many, including me, need the possibility to define the default assignee because of the workflow they have at their company (we do not use components in all projects ...).

Please decide ... either close the issue with "will not be implemented" or take the few days to implement it.
Please.

P.s. same problem I found with the possibility to "close" a project.
All requests have been closed with the information that projects can be archived or that permissions can be removed from the user.
But both solution are not representing the real world. Our dev. need to view a project also years after the project has been closed.
We need to set a status for a project. active, inactive, closed and a filter on the project overview based on this status (default only active).
O.k. wrong item, but may be you can discuss it internally and reopen the related issue.

+1

+1 for being able to change the default assignee - i just set up a load of projects using a PMO admin user account but then realised the issues need to be managed by different users and have no way to change them other than to setup a whole set of new projects and choose a different user as the project lead as i create them.

Jira and Confluence are both fantastic but sometimes, you wonder why they try to restrict something which, although trivial, has a larger impact.

What if the person who is the project lead changes part way through a project - not a valid use case for Atlassian ?

You either assign all issues created to the original project user, or leave them unassignable (what a great idea, lots of issues resolve themselves when no-one is responsible).

Or maybe creating a new project and copying over all content, creating new issues with the new project key and updating all linked issues is seen as an 'easy' workaround rather than allowing a simple edit of the user against the project ?

I've also come across this issue a couple of times already. I'm also voting for JIRA to have the possibility to enter a default assignee which is not either the project lead or unassigned, but some sort of internal dispatcher. That dispatcher and the project lead can be the same person in some of our projects, but in others, they are not.