How is it that a ticket regarding a very basic but important security feature that has been opened 17 years ago  and has gathered over 1000 votes (4th most-voted open issue) still hasn't managed to get on your todo list?

Please mkowalska or  anyone else from Atlassian give us a feasable explanation of why you are ignoring a clear customer desire for this feature and don't fend us off with that generic workflow for feature suggestion. I'm sure that issues like JRASERVER-70821 (basic auth behind a reverse proxy using the Jira app, 1 votes but in progress) or JRASERVER-65812 about adding some debug logging for edge-case situations (0 votes but in progress) are also imporatant, but I'm probably not bright enough to comprehend why these are deemed more important than this feature that should have been implemented in Jira 0.0.1.

IMHO there is only one correct action to take here, and that is to get this issue in progress.

This has been here quite awhile.   Please look for a solution to this. Thank you.

This is easily the most widely requested configuration change within our org. The idea that only full administrators can create projects either leads to 1) lots of extra overhead by the limited number of administrators or 2) lots of extra administrators, which can cause many issues itself. Just create a role that can create projects - how hard can this be?

For those who are still waiting for this solution, I would suggest you to change the way Jira is used. Jira Project doesn't mean real Project. Jira Project means "group of projects with same configuration (issue types, workflows,...)"

The best approach is to use a new issuetype for your real projects and use Issue Links to relate them with other issue types.

This ended up being a game-changer for us. We were seriously considering using Jira at a company-wide level to make use of its project management features. As such, we would have had to raise our user tier by a considerable count to delegate accounts to our user base. But this project creation oversight was a major shortcoming and granting basic users administrator rights in order to do this is asinine. In the end, the option to extend Jira on site was discarded and we looked at other options. No doubt, this is a loss in potential revenue for Atlassian and I dare say that I'm not the only case. Don't get me wrong, I like the product and the benefits it gives to those that use it, but this should have been rectified ages ago.

Atlassian: Don't mislabel this as a feature request or a new idea/upgrade that needs careful long-term consideration and potential addition into a future release. This essential role or permission scheme for users should have been considered from very early on and addressed immediately. You've really dropped the ball on this one given the ongoing nature of this issue and the fact that we're now into 2020. This is a fundamental flaw in your system design. This needs to be given priority and it needs to be fixed.

My company also needs this functionality.  In our specific case we have an external integration account controlled by a third party integrator which currently needs full administrator privileges for the integration to work correctly.  This is a serious risk.

Do you have any plan to provide this feature? We are in need of this feature badly. Please respond at least!

My company needs it also! It is hard to manage so many users with a lot of administrators.

Wow, this has been opened in 2003?

This is going to more and more a thing.

I have scrum masters asking to be able to help, but I don't really want to have a lot of full Jira admins here...

Atlassian please make this happen!

This is becoming a burning issue day by day. Do you have any plan to add this feature? If yes then please provide the estimated timeline.

Don’t be so negative. For many of us, these multi-decade tickets are our form of coping with Atlassian trifling with all of us

First post for this was 21/Jul/2003, at this point it doesn't look like this function is going to make it. 

I join to Larry. I don't understand why jira is so not flexible.

Agreed - I simply do not understand the lack of attention to such a glaring security hole. Administering Jira and Creating Projects should have never been tied together and here we are more than 12 months since the last Atlassian comment and still no activity. In my organization, the people who create projects do not require ANY of the other administrative privileges and, in fact, have made grave errors because they see ALL of the administrative alerts and feel like they should act on them. One person initiated a foreground index and locked everyone out of Jira because they thought they had to do it, thus stopping all work. This person NEEDS the ability to create a project... they don't need anything else. Rule of Least Access - foundational tenet being completely ignored.

Atlassian - can we please get this fixed... SOON?

Could you Atlassian team confirm if the create project permission based on shared templates is planned for any release of jira sw 8.x data center? Thanks.

...And I see that I have found yet another obvious core feature request that has been ignored by Atlassian's team for literally over a decade.
And I wonder why so many of us still support this kind of customer support.

it's still not resolved. just installed a trial version and spent hours banging my head against the wall looking for what'd probably be one of the most obvious security features one would need in a system like this - only to find out that it's simply not there. ridiculous.

Seems not.

Should have been there from day 1

Is this solved in Version 8???

Creating new projects can introduce a slew of issues, unlike the ability to edit project features. (similar perms should exist for creating new schemes of any sort)

'new jira' projects (these containerized things) are not a good solution, as they cut-off one project from another, inhibiting the benefit of sharing common practices.

Anyone else tired of seeing this canned response year after year?

Should have been in version 1

+1

I can't believe that it's not resolved yet.

Is there any progress? I already implemented JIRA server, then when configuring permissions, I discovered that I'm not able to assign project creation permission to Project Managers, without letting them manage users. This makes no sense, why would I give permission to Project Managers to manage users?! That's a deal breaker for my organisation, therefore cancelling plans to use JIRA.

Create a separate permission for Create New project

OMG! 2003 to 2018, 15 years old basic issue, stunning!

Joseph, your list of steps regarding the admin vs sysadmin in the action.xml did the trick. Can the redirect for the end user be updated to go somewhere other than the login page? I can already see users continuing to click on login without reading the access limitation message.

Anyone else been able to do this without problems from those wanting to create projects?

+1 . We need more powerful tools to change permission options.

I second Barbara's comment - It's truly nice to get a broader perspective of the internal Atlassian roadmap and priority list.

@John Young Thank you for lightening this heavy load with your comment 

Hi everyone,

Thanks for your interest in this issue.
This request is considered a potential addition to our longer-term roadmap.

We'll typically review this request in about 12 months time, at which point we’ll consider whether we need to alter its status.

For the nearest future we've decided to prioritize other areas of the Jira Server roadmap, including:

• Performance and stability improvements
• Archiving projects for improved performance
• Optimising the use of custom fields
• Improving performance of boards
• Improving Jira notifications
• Allowing users to edit shared filters and dashboards
• Mobile app for Jira Server

You can learn more about our approach to highly voted server suggestions here.

To learn more on how JAC suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,
Jira Server Product Management

FYI I'm running an older version of JIRA (v7.2.3), so your version might be different from mine.  (Be careful that you just merge the changes when you do this in case Atlassian has modified this file since my version.  I included the actions_original.xml for reference)

Sorry I was a bit careless this morning and didn't save the original version of system-admin-sections.xml.  (that change is pretty easy though)

system-admin-sections.xml

actions.xml

actions_original.xml

Joseph, could you attach your actions.xml file to this ticket to save other people effort? We can use a diff against our own actions file to quickly see what you've changed and easily bring over all/whatever changes we want.

One more if you want your project creators to be able to create and maintain project categories:

in actions.xml: for WebSudoAuthenticate, change role-required to "admin"

also in C:\Program Files\Atlassian\JIRA\atlassian-jira\WEB-INF\classes\webfragment\system-admin-sections.xml

change the section under key="view_categories"

from this:

        <condition class="com.atlassian.jira.plugin.webfragment.conditions.UserIsAdminCondition"/>

to this:

        <conditions type="OR">
            <condition class="com.atlassian.jira.plugin.webfragment.conditions.UserIsProjectAdminCondition"/>
            <condition class="com.atlassian.jira.plugin.webfragment.conditions.UserIsAdminCondition"/>
        </conditions>

jira-administrators will now be able to go to Settings > Projects and configure projects and project categories from that view. 

@Nicolas Le BIHAN

Thank you!  I just set this up on a test JIRA sever and it works wonderfully.  I can now have my "project administrators" (people who can create and manage projects) in the jira-administrators group and my "system administrators" in the jira-system-administrators group.

To clarify: This means people in the jira-administrators group can create and maintain projects and basically do all the normal day-to-day stuff a user with that permission should have, but they don't have access to anything in the System administration section (except the administer projects view which is specifically allowed in the below settings I used)

I don't know why Atlassian doesn't just simply give us access to change the settings in this actions.xml file from a web interface.. this would effectively solve this issue.  Anyway, editing the file is relatively simple.

This is what I did:

Step 1

Set up JIRA System Administrators role by creating "jira-system-administrators" group - this is mapped to "sysadmin" in actions.xml:

On JIRA users administration screen:

Create jira-system-administrators group and add appropriate users to it.

On JIRA System administration screen under Global permissions:

Add the group "jira-system-administrators" to the Permission "JIRA System Administrators"

Remove jira-administrators from the JIRA System Administrators permission.

https://confluence.atlassian.com/adminjiraserver072/managing-global-permissions-828787760.html#Managingglobalpermissions-sysadminAboutJIRASystemAdministratorsandJIRAAdministrators

Step 2

(on Windows) Change the actions.xml file here (use a tool that can handle unix line endings - I used TED Notepad):  C:\Program Files\Atlassian\JIRA\atlassian-jira\WEB-INF\classes

• COPY THE actions.xml file to the desktop or some other location where it can be edited without administrative privileges. 
• Make a backup copy of actions.xml
• Make the required changes to actions.xml.
• copy the modified actions.xml and replace the one in the program files folder.

I'd guess the mentioned changes in the previous comment are adequate, but I went ahead and cleaned house, effectively eliminating the permissions for everything under the administration section.

I made a huge number of changes to my actions.xml, searching for "admin" and replacing with "sysadmin".

These are the only permissions that have roles-required="admin":

DeleteProject

SelectProjectScheme

SelectProjectWorkflowScheme

SelectProjectWorkflowSchemeStep2

SelectProjectWorkflowSchemeStep3

SelectProjectCategory

SelectProjectPermissionScheme

SelectProjectIssueSecurityScheme

IndexProject

ViewProjectCategories

AddProjectCategory

EditProjectCategory

DeleteProjectCategory

SelectIssueTypeSchemeForProject

MigrateIssueTypes

ViewStatuses

ViewWorkflowsForStatus

EditStatus

DeleteStatus

MigrationSummary

Hi,

One thing you can to limit access to "IT" parameters like ldap and mail configuration when you need to give admin rights to users if they wnat to create project is the following:

vi /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/actions.xml

and modify accordingly to following:

vi /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/actions.xml

    <action name="admin.ViewApplicationProperties" alias="ViewApplicationProperties" roles-required="sysadmin">
        <view name="success">/secure/admin/jira/views/applicationproperties.jsp</view>
    </action>

    <action name="admin.ApplicationAccess" alias="ApplicationAccess" roles-required="sysadmin">
        <view name="success" type="soy">:application-roles/JIRA.Templates.Admin.ApplicationAccess.page</view>
    </action>

    <action name="admin.user.UserBrowser" alias="UserBrowser" roles-required="sysadmin">
        <view name="success">/secure/admin/user/views/userbrowser.jsp</view>
    </action>

Restart JIRA to take this in account. The behavior will be, if a jira-administrators user will select one of the “Application”, “Add-ons”, “User management” or “System” choice to redirect to the login page and an error about necessary system administrator role when they only belongs to jira adminbistrators but system administrators .

If you have JIRA Server + ScriptRunner, one thing you can do is create a one or more template projects, and then train a junior admin to simply use the "Copy Project" built in script from ScriptRunner.

ScriptRunner has helped us reduce the total number of JIRA admins to 3 for ~1200 users, while also eliminating variance between projects that should be kept similar for reporting purposes. Bonus, this method does not require the junior admin to learn the intricacies of project schemes in order to satisfy new project requests unassisted. 

At the same time we implemented this change, I also re-wrote the permission and notification schemes to use project roles rather than groups, so that the junior admin only has to set the Lead, who can then deal with setting any other permissions themselves on the Roles tab of their project.

It isn't an ideal solution and doesn't cover every corner case, but it beats the heck out of having a bazillion admins

I have over 80 admins for 3000+ users.   ( Atlassian: Enterprise means more than just clustering...)

Hopefully we are automating project creation and removing the admins this month.

This is so ridiculous!  I have 20 of my users set as system administrators for a total of 58 users!  This needs to be fixed.

+1

+∞ 

+1

I first started following JIRASERVER-1431 before my daughter was born.  That's the same daughter I just dropped off for eighth grade.

Through all the trials and tribulations of parenthood, throughout job changes and political changes, JIRASERVER-1431 has been a constant, steadfast, reliable companion. Always there, never changing.  It's been a firm rock in a sea of uncertainty.

I hope that, after I live a long and interesting life, and I finally die peacefully at home, surrounded by my friends and loved ones, far in the future... I hope that you will read the status of JIRASERVER-1431 at my funeral, so that future generations can continue to watch the progress of this issue with interest, as I have for these many years.

In my opinion this should be a basic feature and now I see this task is open for over 14 years ..... please don't show me your prioritization matrix.

This functionality is definitely needed and a long time overdue.  I like Pablos comment on template creation also.

With a global permission to "Create project with shared configuration" it would be fine for lots of scenarios. We as admins could create   "project templates", with desired screens, fields, workflows, etc  and let the project leaders create projects on demand using one of the provided project templates, that would share the schemes instad of duplicate the template ones. If we could stablish wich projects they can use as templates, that would be even better. In this way, the leaders get their projects quick, and they don´t need to be administrators or deal with scheme setup.

I can't believe that it's taking such a long time to decouple this functionality and make it flexible enough for Project Administrators to be able to create their own projects.  Atlassian, what's the delay?

Yup, PMs should not need to be global admins. Divide and conquer please!

I hope my grandchildren will be able to create a JIRA project without being an global administrator! What a shame...

+1

+1

so it been more than a year since last Atlassian update on the issue. We still have a permanent need to pay salary for a special man that dedicated to creating project on behalf of our 35+ PMs in 8 dev teams.....

+1

+1

+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.

Ladies and gentlemen, please.

Everyone who been involved in development knows, that not all features are as easy to implement, as it might appear to the untrained eye. Secondly; Atlassian is in full control of what the strategy for their products looks like, and perhaps this just doesn't fit the parameters of the direction Atlassian is headed in.

I have personally missed this feature ever since I started using JIRA (today I'm the product owner of JIRA in our organization), and like you I don't understand why Atlassian would promote the idea of more administrators; I mean, come on!?

That being said: I am very pleased with JIRA as an issue tracking and task management system, in fact I think it's second to none at what it does. Additionally I fully trust that Atlassian knows what they are doing, and I believe that there's a good reason for not implementing this feature. Still I hope that we'll move past this obstacle in some way or another, soon.

If anyone would like to know how I manage this inconvenience, please feel free to contact me.

I couldn't agree more.

I think this features is quite basic! Who wants to put all the world admin... come on !

Maybe someone needs to let Mike know. Agree. I realize this is "just" a product feature request but if it's been open for 13 years....maybe Atlassian hopes everyone will give up asking.

WTF. THIS ISSUE IS OPEN SINCE 2003! Wow. Shocking. How many employees does Atlassian have working on jira? This is rediculous.

I would also like this feature. This is a currently a big gap in the way I would like to use this software at my company.

In our case, is very important to have this funcionality available, so I give +1 to the proposal.

+1 on this feature. It would take a big load off the admin group for us.

@Dave Meyer

Any status update on a planned release timeframe? The Delegated Project Creator doesn't work for us because the mail server rejects the mail being created by it and the default JIRA API for it doesn't allow the add-in to create e-mails in a format that the mail server will accept. We are stuck right now. https://wittified.atlassian.net/browse/PCFJ-210

Thanks

@Dave Meyer: +10000! We trust in you Dave! Regards from Bcn

@Dave Meyer: +1

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

What you surely meant to say is that the lack of the feature is by inherently poor design for something that is allegedly commercial grade software for which I do hold Atlassian responsible. If you take a look at the last comment on this ticket, which is my comment, and you'll understand why I say that. That ticket was closed after being open for years. Atlassian don't want to fix it or anything else related to permission sets - as the evidence shows (and some of the other linked tickets that have been closed indicate too). The entire permission scheme is woefully inadequate. In order to manage users you have to be an admin. This is dangerous. Giving people the keys to the kingdom when they only need to manage users is a recipe for disaster.

This functionality would be nice but we can't blame Atlassian for interrupting our individual business capability, when the feature (or lack thereof) is by design. We are modifying our processes to match the options in JIRA, and it's really not that big a deal. Alternatively there's always the Project Creator plugin.