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

+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

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.

+1. We held a meeting recently about how JIRA is now actively harming what we do as a business for myriad reasons. We are actively looking at alternatives.

+1 from me as well. Our PM's require this functionality, but we don't want to have a bunch of Admins. Not having this puts us in quite a bind.

I tried installing this (Standalone Project Template v 1.1.1) for it says it is for versions 7.0.0 - 7.1.5 . But, it is not compatible with our version (which is 7.1.1) so I have removed it.

We would like to see new permission added - too many admins.

I appreciate that Jira wishes to look a holistic solutions but being able to grant create/edit/view only type rights is a basic requirement of any "enterprise" solution. While the issue of fine grain permissions and how they are managed may well require a holistic view and involve much review and debate etc. the basics should already be covered and it is concerning that they are not. I will also note that this ticket was opened in 2003, which means that it has taken over a decade for what is a relatively basic feature of security permissions to reach JIRAs to do list?

@Normand Carbonneau +1 - exactly. This should absolutely be an out-of-the-box capability. Plugins should not be required to achieve this. But we already knew that. That's why we're all over this ticket.

Hi Raul, no problem. What I am trying to explain is that even if a plugin is free, I will never use it. We are talking about a feature that I am expecting as an out of the box feature for a professional product. Using a plugin means a high risk of incompatibilities with future updates on the cloud. I want this feature delivered and supported by Atlassian. Especially when dealing with security.

I want to push my plugins to the CLOUD... but Atlassian don't wants to "verify" me because I don't make PAID addons, my addons are FREE..
Sorry @Normad Carboneau and @Gary Mellor... I am only trying to find a solution for this request... :_(

ATLASSIAN PEOPLE ¿¿¿WHERE ARE YOU???

Raul, what about CLOUD users? We are paying A LOT of money annually and this is the reason why we are complaining. Third party plugins is NOT an option.

Giving individuals site-admin permission so that they can create projects having been on a (internal / external) course and having taken an exam is not a solution by any measure. It simply highlights how farcical it is that JIRA does not already have this basic permission (along with a good many others beyond the scope of this ticket). Your 'solution' means people have access to the system beyond their needs so they can do something very simple. It is also expensive as a 'solution' since it means they either need to be sent to an external training course (costs involved and loss of productivity) or be put on an internal training course (cheaper but an increased loss in productivity since more people are involved: someone who already knows JIRA within the company training those who don't). While it 'solves' the problem (people can now create projects) it has taken training courses, cost money and personal productivity, we still have the same end result: taking a hammer to crack a nutshell and we still have people with permissions well beyond what they require. So, in fact, your solution is not a solution, it's asking for trouble as those same individuals can still wreck the system either deliberately or inadvertently. Here is all we're asking for here:

Use case: As a JIRA administrator I want to assign a Create Project permission to an end user so that they can create their own projects.

Job done.

The plugin is: https://marketplace.atlassian.com/plugins/com.rauliki.standaloneProjectTemplate.StandaloneProjectTemplate/server/overview

The source of my plugin:
https://jirasupport.wordpress.com/2015/12/18/tutorial-creating-a-project-template-with-standalone-artifacts-in-jira-7/

In my company, we have "homologate" a few people (Agile Coaches) through a JIRA Project Admin course and a validation exam.
Now they are "site-admins" (not system-admins).. and yes, they have the "keys" of the kingdom...

The first time, they make mistakes ( changing shared worklows as they want without talk with the responsibles of the other projects, etc..), for this reason is important to make a validation exam. Otherwise I have created a plugin of a "project template" to allow the Agile Coaches create new independent projects (with independent scheme, field config, permissions, workflows, ...) it's a little bit inefficient, but is the solution

Regards

Yes.... I think we can try (or Atlassian) to "talk" with the company of this plugin to homologate for cloud.... it's only an idea

@Raul Pelaez, that is for server only. It also assumes that the user wishes to use pre-defined templates. I simply need to delegate a permission to end-users, such as Team Leads, Project Leads, Product Managers etc., that will allow them to create their own projects howsoever they choose and without having to give them 'the keys to the kingdom' to have them achieve it. Simple.

Hi @Gary Mellor, the plugin is the "Delegated Project Creator" .. I think it works on Datacenter and It's Atlassian verified...
https://jirasupport.wordpress.com/2016/02/01/delegated-project-creator-for-jira-addon/

"The Delegated Project Creator for JIRA add-on allows JIRA administrators to create templates of the schemes needed for commonly used project configurations. Create as many different templates as you need to handle new project requests.

Then, identify the trusted groups who can create projects from those templates, or request projects. Those trusted group members can then do self-service of your routine project requests, freeing up your JIRA Administrators for more important work!

A history is maintained of all project requests, collecting valuable information about who requested a project and why."

@Raul Pelaez: And I'm very happy for you. Is that plugin available in the cloud as well server version? If so, what is its name because it seems that the availability of it has somehow escaped the attention of all the voters and watchers on this issue. For years.