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

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

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.

It's very easy to know why Atlassian don't want to do this change... BECAUSE there is a PLUGIN that do exactly this. And the JIRA ECOSYSTEM is important TOO.
JIRA must be a SIMPLE issue tracker by default and if we need some EXTRA functionalities, we can use the PLUGINS. For me It's a PERFECT great tool!

Regards

Product management must follow the priorities set by the company. The priority of Atlassian in the last few years has shifted, from delighting its base of technical users with unprecedented value, to growth in adjacent markets: sell to product management teams, digital marketing companies etc.
In the previous years it would have been impossible to compete with Atlassian offerings. Now new space is opening up for competitors. I will not name anyone, but personally after 9 years and multiple products, am now close to buying something from a competitor.

Gary, you have it totally right. The most frustrating part for me is to see Atlassian putting thousands of hours of effort on so many things that are useless for most of us (bells and whistles), and still seeing fundamental things like that ignored. I have been a strong advocate for JIRA and Confluence over the years, but even the most convinced people like me are starting to have doubts. We are actually in the process of evaluating another software... This would be totally impossible for us to act like this with our customers. We would no longer be in business for sure.

We had a similar problem where historic issues got snowed under other priorities. We solved it by having a couple engineers devoted to clean them up, one after the other. In a couple of months they were able to clean out most of them - except for a couple which required a too heavy refactoring. The cost of this investment outweighed the bad buzz in the field about our responsiveness and customer focus.

Francis

@Dave Meyer.

RE: your post in this thread on 04/Jan/2016:

----------

"...The ability to create new projects without full JIRA administrator permission is one of the initial areas we will investigate, so this is a high priority for our team. While we cannot provide any information on a planned solution or release date, we will update this issue as we progress..."

...and my comment yesterday:

"...we can expect to wait approximately another three years for a further cut 'n' paste update from whoever the Product Manager happens to be at that time...."

----------

Thank you for your reply, which provided some clarity to this discussion. What I think all the voters and watchers on much needed fundamental features such as this can take away from this is that while your comment, referenced above, was honest, my comment was accurate.

The first of the twelve principles that comprise the Agile Manifesto is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Perhaps you could also provide some clarity on the point at which Atlassian lost sight of this? I am not specifically referencing this ticket when I say that either nor am I deliberately trying to be inflammatory.

Regarding your specific point yesterday: "...I would wager this is the same for any product development team at any growing software company practicing agile development..."

My employer is going through growing pains as it emerges from start-up mode and is maturing everything it does. Where I work the customer is King. If they need a feature to improve their UX or add value to what they do then that is added as a higher priority on our roadmap than, for example, pretty UI changes. It doesn't get to the point that the customer threatens to leave us after we haven't implemented it years after they originally asked for it. JIRA has been doing this for years.

Perhaps the difference here is that the voters and watchers on not just this issue but other much-needed, basic features, is in the nomenclature: Atlassian are practising Agile development while they're actually delivering it.

There are a myriad other such tickets where the voters and watchers are over a thousand in some cases and the ticket has been open for years with people, like me, complaining bitterly at the lack of updates or that they have, in fact, been closed as Won't Fix.

Dave, customers who are consistently failed by a business usually stop giving them their custom, it is just a matter of time.

Furthermore, to address your specific claim that "...We review and update all highly-voted feature requests on a regular basis...", I believe the facts on this ticket alone speak for themselves:

Therefore your assertion would seem to be somewhat adrift of the reality here. Over five years before the first update as far as I can tell and then another gap of almost three years. I guess 'regular basis' and 'highly-voted' are subjective terms. It seems that Atlassian considers updates years apart to constitute 'regular basis' and that, at the time of writing, 531 voters and 273 watchers (ignoring all the frustrated commenters) does not amount to 'highly-voted' or am I incorrect in my conclusions here?

Hi gary.mellor,

We review and update all highly-voted feature requests on a regular basis because we think it's important to give our customers a recent and honest assessment of the status of a feature request, even if that status has not changed. The reality is that we will only be able to address a small fraction of all the open feature requests at a given time, so the vast majority will not see a change in status. We absolutely recognize that this is frustrating and disappointing, but being honest about the status is important to us, even when the news is usually not good.

Let me be perfectly clear: when Roy said that it was a feature we wanted to take a look at in the near future, this was accurate. We were considering it at the time, but ultimately we focused on other priorities and were not able to address it then. When we update issues, we make an effort to provide an honest assessment about the knowledge we have at the time, but this isn't the same as a guarantee. We continuously re-evaluate our roadmap, priorities, and investments internally within the JIRA team as well as responding to the larger needs of Atlassian. I would wager this is the same for any product development team at any growing software company practicing agile development.

Dave Meyer
JIRA Product Management

I think opting to not hold your breath for a fix is the right thing to do. Asphyxia can ultimately cause death, which would undoubtedly arise before a solution materialised from Atlassian. Although, thinking about it, it would probably lead to less suffering in the long run On a serious note, it should not be down to end users to craft this basic requirement for themselves using the API.

Here's an observation regarding timelines for us all relating to comments by Product Managers on this very ticket:

---------------------------------------------

Roy Krishna, JIRA Product Management, added a comment - 21/Jan/2013 4:40 AM

"Thanks so much for your votes and comments on this feature request. This is a feature that we would like to take a look at in the near future..."

Dave Meyer, Product Manager, JIRA Platform, added a comment - 04/Jan/2016 1:23 AM

"Thanks for voting and commenting on this issue...Simplifying project setup, configuration, and maintenance is one of the JIRA team's top priorities right now..."

---------------------------------------------

So, if this is anything to go by we can expect to wait approximately another three years for a further cut 'n' paste update from whoever the Product Manager happens to be at that time. Splendid! I'll add a reminder in Outlook now.

Just spent 25 minutes digging through JIRA permissions to try to work out why nobody but me could create projects, before eventually finding this feature request from 13 years ago. I know there's a response from 3 months ago saying "We're working on it", but I'm not holding my breath.
I'm currently building a simple web interface which will let our team create new projects using the JIRA REST API (using my API key, but that's fine). It requires less effort than making everyone an administrator and making sure they don't break anything.

Someone start the user group, and generate members and drive some critical feedback that so public Atlassian has to respond.

What we need is an Atlassian User's Group for large customers 5K, 10K, 10K+ user licenses. Even if it online or only meets once a year at the summit.

Spot on Gary!

@Dave Meyer, I agree with what Michael said immediately after your comment "...we do agree and are working on long-term changes across JIRA project setup, maintenance, configuration, and administration..." - I've seen you comment on other bugs that I would deem as critical/must-haves and then there has been nothing. For years. There are a whole bunch of issues that get closed off as Won't Fix that beggar belief. The example Greg quotes being a perfect illustration. There are a number that I am watching that have had zero updates in years except the periodic cut and paste from you: "...Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience...", despite the voters and watchers being in excess of several hundred. Marge is probably spot-on with her assertion that management don't likely recognise the need. As per my comment on this ticket I wonder if management would sit up and listen if all the voters and watchers on that ticket alone represented enterprise customers who decided to simply leave Atlassian and go elsewhere? It seems that month after month our subscription is readily received and in return we get unnecessary bells and whistles that aren't critical (but apparently management thinks are) at the expense of proper user experience and key functionality. I'd happily go without rounded corners on parts of the UI to have some of these critical issues and oversights fixed instead. JRA-24907 drives me insane daily as we have many variations on the case of some labels which means that the very thing that labels is supposed to assist (searching) ends up being completely useless because functionality is not the same as Functionality, for example. That little gem has been open since 2011! As Greg states, it's as if Atlassian seems to think that having a reliable search is a 'nice to have' feature. Never mind, keep giving the masses the bells and whistles instead, right, 'cos they're super-useful.