Created 21 years ago. Unassigned and the last update was 8 years ago. This represents Atlassian more than anything. 

Addin my Vote - We need to create a Project for each new Client. I should not need to give my Project Managers Admin rights to the entire system, to do this basic task.

Hi, in case you are up for a third party solution that's hosted by Atlassian.

Project Templates for Jira offers an intuitive way to design custom project templates and allow non-admins to create Jira projects based on them.

• Customize the templates configuration to meet your unique requirements

• Give non-admins template specific project creation power 

• Customize the UX & information displayed to non-admins 

• Clone and predefine project versions, components, project role actors and issues including their hierarchy.

• Avoid the technical debt of unnecessary created Jira schemes/configurations

The app is built on Forge with no data egress, no sensible information stored and completely hosted in Atlassian's cloud infrastructure. 
Please let our support know if you have any questions.

@Derek Fields, I need these people to create projects which is why I'm complaining about it on this Jira Cloud issue thread about granular permissions to create projects. We usually have ten to fifteen new jobs a month and the Jira projects associated with them are created by their project manager or controls engineer. Right now that means every PM and controls engineer has to be a Jira administrator. My company is unable and unwilling to create a central Jira authority, right now it's just me trying to convince people to stop using post-it notes and I'm too busy to go around creating everyone's project for them.

@Roberto Ialino, archiving projects is a feature of Jira Cloud Premium which is double the cost of Standard. Using permissions to hide old projects works, but only for people that aren't Administrators, but right now everyone that cares is an administrator, so we can't actually hide these things.

Hi @Derek Fileds for instances with 2k users you need a certain number of administrators since UNFORTUNATELLY the admin permission are not granular enough.
On large organization you cannot apply adminin permission for create new project (for example) because the same permission enable the user management. This have completely no sense expecially now that there is an increase of security requirements.
Atlassian NEED TO DO SOMETHING since this administration model does not work at all.

@IBrown_BluePrint - if you create a permission schema ad hoc that restrict to only some people the visibility (only admins for example), you can archive projects.
About the cost you are mentioning is not clear to me at all.

Best regards

@IBrown_BluePrint - Do you really need 20 Jira administrators? In my experience, even the largest organizations can usually get by with 2-3 Jira administrators. When I see that number of admins, it makes me wonder whether there are too many cooks in the kitchen. It makes me shudder to think that they are "un-savvy enough to ..." Why would you give people who don't know what they are doing Jira admin permission?

I talked my manufacturing company to move to Jira from literal post-it notes and it's junk like this that is getting me tons of pushback. I now have 20 Jira administrators, most of which are un-savvy enough to delete the entire site if they got lost enough, just so they can create projects.

The real kick in the pants is we've already got multiple pages of projects in less than a year and we'd have to literally pay double the price to unlock the ability to archive them. Can't hide them with restrictive permissions either because everyone has to be a damn admin to create new projects!

This isn't going to get implemented in any of our lifetimes. :')

High priority for 6 years.

These kinds of "issues" that stay without an update for years despite increasing number of support requests makes me want to migrate away to a solution like ClickUp.

My suggestion is to solve it with some plugin 

WOW!

This issue has 18 years!! It can now has a definitive Driver´s License.
We still need to grant a high level permission to people that just need the ability to create classic projects (the name was changed to Company-managed now).
Anyone from Atlassian is monitoring this??

I just realized that this issue - `JIRACLOUD-1431` – turned eighteen years old on March 12th of this year.  This issue is now old enough to vote!  Congratulations, this issue.

I first comment on this issue in 2007, when this issue was only four years old.  Occasionally, I get email with comments, and I like to check in on it and see how it is doing.

When this issue turns twenty, I think all us commenters should get together for a party!

https://getsupport.atlassian.com/browse/JST-640337

To find out that this is not a new issue but is years old is disheartening. Requiring admin rights for project creation is just brain dead design.

@Patrick Peak and @All,
As some users have mentioned, permission rules seem to need an overhaul. I myself have experienced limitations or inconsistencies between rules despite the depth of customization available. I don't believe permissions should ever have conflicts. If your permission structure is sound it should simply notify a user / admin when access cannot be granted and why.

Administrator access at the project level tends to be a common request.

I tend to like the idea of defining reusable but customizable settings like:

1. Roles: defines what a user can do (account admin, project admin, manager, contributor, member, etcetera)
2. Groups: defines what users can access (Jira instance, company, department, team, etcetera)

In this scenario users are assigned roles for each group and permission schemes auto generate (no need to edit).

• Example 1: new user is a member of Jira instance
• Example 2: CFO is a member of Jira instance, manager of company, project admin of department, contributor of team(s)

As it stands Jira has:

Permissions overview "simplified explanation"

1. Permissions Schemes in projects (used to define role permissions in projects)
2. Roles in permission schemes (used to define user permissions in specific roles)
3. Groups in administration (used to define I think site wide permissions, but seems too ill-defined  / flexible)
4. Groups like "site-admin" are a bit confusing as this is more of a role classification
5. Organizations in administration > security (don't think this has much to do with permission management yet)

Also not sure if this issue is related to the following issues, so didn't want to impose they be linked to this one.

JSDSERVER-5072

JPOSERVER-1220

JPOCLOUD-1220

@Karin that is correct. Thanks!

@Barbara - Sharlyne might be referring to the option to get this working Jira server by using a plugin. We do this in our company on our Server instance with Delegated Project Creator for Jira

It allows you to set up templates for the creation of projects and to assign permissions to specific groups to then use the templates and create projects from them. Unfortunately this plugin is not available in the Cloud instance, so technically there is a way to do this on Server that is not there on Cloud, just not out of the box. Hope that helps.

@Sharlyne Tsai: this does not work on Jira Server. There the status has been set to "future considerations", which means they won't even consider it for another year, more likely year*s*.

I'm disheartened that a request since 2003 which has 2 active tickets that relate to the topic and still no solution or actively working towards a solution to this challenge. Though an update in 2016 indicates it's important yet the ticket is still only in an 'open' state. What's even more depressing is that it works in server!!! Why is the cloud behind? What is going on Atlassian??

Just realised I need to have a whole bunch of enthusiastic admins running amok in the system just to enable something as simple as creating a project? Really, this can't be right, perhaps in the early days but not now, surely!

+1 from me!

+1

This is a showstopper, all businesses need to make sure that all their user permission levels are isolated to their job description, if not they will not pass certain audits and not being able to get their InfoSec certificate.

Any updates on this? This is such a basic but important feature. Giving admin permissions to everyone who needs to create projects is simply not reasonable. 

With the recent decoupling of Software, Core and Service Desk from a licensing standpoint, this seems like it should be part-and-parcel. Is there any update since the last one from December 2016?

Hi, we like Atlassian platform but having to pay for the relevant plugin is beyond our budget for now. I vote for this role to be implemented in the standard package.

+1

We currently use Delegated Project Creator for JIRA in our in house instance and that works great. We are looking at moving onto On Demand for our Atlassian products (Confluence and JIRA Software) but the inability to separate the creation of projects from full on JIRA Administration is putting the brakes on for us. If we could have the Delegated Project Creator add on in the On Demand version or some similar functionality, where projects can be created using predefined templates only by users outside of the JIRA Administrator pool, that would be great.

Atlassian, any updates on this item?

+1

+1

+1

@Aparna: That's what I do, except I have equipped our support organization with admin privileges, so we have a dedicated team for project creation. It works well.

Aparna, yes, creating projects with shared configuration is simple.

However, I think you will find as your organization grows that you don't want to personally create every project, and that you would like to begin training additional JIRA admins so that you can do other things, like take a whole day off.

In other words, the point of this permission is to begin to create a security infrastructure that allows for delegation of duties, instead of keeping us in the current all-or-nothing structure.

I actually want to remove my +1 from this. We have recently rolled out JIRA across my organization and I had initially considered this to be a roadblock. However, it helps me to have project creation centralized as it enforces my teams use standard workflows, screens, and so on. I represent project governance at my org and this enables my team to have consistent process across all our projects. So lack of this feature has turned out to be a blessing in disguise. I do not plan to give my project managers access to be able to create their own projects for the foreseeable future. 

NOTE: I create projects using "create with shared config" feature and I have one project that has all the right settings that I use every time. the overall process of creating a project and related confluence space takes me about 10 minutes. 

+1

+1 for us too. We are a businness school based in Switzerland and we need to make "Create New Project" a separate global level permission.

You shouldn't need to be a Jira-Admin to create a project..

Pascal

Agree, we employ a project manager who needs this function without being to admin the whole JIRA on prem install

@Jacques Papper: They way we handle this is by equipping our Support Department with Administrative permissions, so that customers can ask for project creation via a designed template in the Service Desk portal. Works well.

How do current users deal with this ? It's simply unacceptable to give admin permissions to everyone who needs to create projects no ? 

+1 On need for allowing individual or a group to create their own projects.  Granting Admin access is too lax.  

Hi tracy.rhinehart,

Please see the related update on JRA-3156 from yesterday. We are working hard on both JIRA project configuration and authentication across our Cloud, Server, and Data Center products.

Regards,
Dave Meyer
Senior Product Manager, JIRA

Any update? We are having a hard time broadening the use of JIRA since we have to give users the keys to the kingdom to create projects. Not a well thought-out security model, IMO. That, in combination with no SAML authentication is making JIRA a tough sell to our security folks. It sounds like there's finally movement on the SAML front, curious about this as well.

Sorry for the duplicate comments, but when I leave a comment, it doesn't display on the JIRA ticket itself - I've now received 2 emails but can't see the comments on here, after forcing a cache refresh too.

Maybe I've just found another bug in JIRA - when you get 180+ comments on a single ticket, it stops displaying new ones. Or possibly when the length of all comments combined exceeds 65,000 character or some other value, it stops displaying new ones. Or maybe the server hamsters are just slow today.

Throw another vote on the pile...

Shall I hold my breath.

@Dave Meyer
Any update on this? 

This is an absolute must have!! I am new to JIRA and just spent hours trying to figure out how to do this and now I see that was a waste of time.  There needs to be another layer like this for security purposes.  There is not need for a large group of the people that use this to have this much access.  It can't be that hard.  We spend thousands of dollars and what is supposed to be the leader in project management and you still haven't done this.  Very sad.

Hi Dave,

Can you please let the customers know on when this could be done. It appears that this is something atlassian plans to do but it has not been done it yet.

Can you give us some insight after you talk to actual development team (And/or Marketing team) what the real problem is to keep this very legitimate requirement from customers pending for so long.

Or, let us know some opensource add-on that can enable this functionality?

Regards,
Mona

"and I can't fathom how some people are so bent out of shape about it. It's really funny."

Says it all, really.

Since version 2.1 and still dont fixed... this is incredible... no words.

Please, increase the issue priority to critical for next releases. I think that this is a security update in your software. Some JIRA users must be able to create projects without administration privileges like at Confluence and Bitbucket.

Cheers,
Felipe.

@Dave: Thank you. Have a nice day .

I believe that Atlassian is sincere about this, so take a deep breath and let's assume that this is addressed in one of the two coming major releases.

Improving project configuration and maintenance are going to be a sustained investment for the foreseeable future (I know I reference "foreseeable future" a lot on jira.atlassian.com). We would love to move faster or have more to show at this time, but nevertheless we are extremely committed to improving this aspect of JIRA.

Dave Meyer
Senior Product Manager, JIRA

@Greg: :-D.

Yes, I am entertaining the idea that Atlassian had more important issues to prioritize for the last 13 years, and I am acknowledging the fact that Atlassian can do whatever they want with their product. Rather than focussing one minor inconvenience and unfavorable priorities, I remain focused on how great JIRA is despite its flaws. This feature is nothing more than an additional administrative burden, one I can live with if need be. It's a nice-to-have scenario, it's really not a big problem for me, and I can't fathom how some people are so bent out of shape about it. It's really funny.

If this really mean that much to you, I would refer you to the second paragraph in Atlassian's most recent update:

• "Simplifying project setup, configuration, and maintenance is one of the JIRA team's top priorities right now. We are in the early stages of a big investment in making it easier to get started with a JIRA project and maintain a large number of projects at scale.".

I believe that Atlassian is sincere about this, so take a deep breath and let's assume that this is addressed in one of the two coming major releases.

Your argument is pretty facile when they've had 13 years to implement this.

Are you seriously suggesting that over 13 years, they've always had something more important to work on, than this issue? Especially when this is basic functionality in any serious enterprise application?

Also you seem to have a myopic focus on just this issue. Yes, perhaps on this issue, they have just barely met the minimum level people would expect for responsive communication. But across the other top 30 voted issues/enhancements, they are woefully inadequate.

@Nick: When arguing against people who are cussing, cursing and shouting, it is impossible to remain civil and not be condescending. Bad language is simply not a proper way to get your point across in a public forum.

I second Peter's comment; I think Atlassian is decent at providing feedback and I would not expect them to comment twice on the same issue. And they updated the ticket in January this year. What more do you expect? If people would actually read older comments and review the ticket status, we would deal with a lot less noise.

@Nick, I don't want to be Atlassian advocate, but in this specific issue they did a pretty good job communicating their plans. The latest being from June, that's pretty clear and recent.

Dave Meyer added a comment - 14/Jun/2016 12:01 AM

As stated in the update from earlier this year, we are actively planning how to deliver this feature in a way that solves as many of the requests on this issue while still maintaining power and flexibility for the tens of thousands of customers who are using the existing permission scheme system.

Dave Meyer
JIRA Product Management

@Jon - There's no need to be condescending to people trying to have their priorities recognized. Do we know what is going on with Atlassian's backlog? No. So it's true that we can't say with certainty the nature of the fact that the top rated issues aren't getting addressed. This could be addressed if we got better communication FROM Atlassian, though.  Usually all we get is "this isn't on our roadmap", and with that little to go on, the customer base will grow more and more frustrated.

Additionally, we as customers do have the right to voice our opinions, that's the whole point of a space like this.  If Atlassian does not prioritize the things that are important to us, then it's entirely appropriate for us to voice our opinions to try to get them to recognize what we feel is a priority.

This gets to what I said in the comments of JRA-1973:  "I don’t think the discontent of the user base is going to be going down on its own without addressing these high voted basic functionality issues, or much better communication, OPEN communication, for WHY these are not being worked on. Without those I’d guess that the frustration will boil over more frequently."

Again; we don't know what's going on in Atlassians internal backlog. Could be that the UI attention covers a massive in-dept restructuring of their product, to support the future responsive web needs.

What it boils down to though is whether or not the inconveniences outweigh the benefits, and that answer is clear to me.

Good day sir.

"Everyone who been involved in development knows, that not all features are as easy to implement, as it might appear to the untrained eye."

Everyone who has been involved in development also knows, that some features are much more important than others to implement. For example, Atlassian has spent the last little while "improving" the UI of Jira, instead of doing enhancements like this.

Actually, the UI was fine and already usable. I some ways I prefer the old UI to the new one. I would much rather preferred that Atlassian work on this issue, and the other top 10 voted items, because that would deliver me value for the money my company pays. We get little to no value out of the UI changes they have made, because the old UI was fine.