Hi Everyone,

I know you all prefer to have this feature built in from Jira.
But as we all know that can take years!

We created a (paid) plugin Delegated Administration for Jira (support DC from Jira 9.xx)
This plugin let you delegate the "create project" permission and some other admin permissions if you want.

This plugin is all about delegating administration permissions, so if there is something you wish you could delegate and not exist in the plugin, please open us a ticket request and we will add it.

We are giving 20% discount till end of 2023, just contact us via ticket and we will give it to you.

Hope you will find it useful

Thanks,
Pitronote Team

This would be a useful feature for our company.

I tought that the vote function was there to indicate my interest in a feature request...

But just to make sure that Atlassian does understand that I'm still interested in that feature.  I will not repeat all the reasons why I'm still interested, it's been all clearly documented in the other comments.

Here it is written clearly:  I am still interested in that feature!

Thank you

I am glad I am not alone with this..  It finally hit me when I am slowly wandering back into Jira Administration.. this would be very handy to have  all the above comments reflect the same concerns with having this permission without having to assign the user as an Administrator.  It would be nice to have, so if my comment upticks it, great!!

So....  just hit this issue for the first time and browsing google to see if anyone else felt this was a huge missing item from Jira permissions.  Reading this is a bit disturbing, as an organisation that is currently considering a big increase in Jira usage.

It's nice to be in a crowd of  1200 (socially distanced) upvoters, but it does make me wonder how many votes are required before Atlassian will fix a defect - because this is a functional defect.

For those who find it useful.

We created a plugin that gives this feature (among other things).

Delegated Administration for Jira

Here is also a 50% off coupon: https://promo.atlassian.com/JMCLDP

Best Regards,
Pitronote Team

2185e9be7a59 thing is that Atlassian (company) just don't care about us (you, me and rest of their customers).

Allow me to present you these proofs for my claim:

1. (shameless plug: this is my comment ): https://jira.atlassian.com/browse/JSWSERVER-9167?focusedCommentId=1611502&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1611502
2. my favorite comment (made by john31) that pretty much sums up how Atlassian (company) treats all of us: https://jira.atlassian.com/browse/JRASERVER-1431?focusedCommentId=1622073&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1622073

Note to Atalassian (engineers) staff that actually does all the work (people in development, QA, infrastructure, support, etc): I actually appreciate your hard work and I do understand that your matrix (operating systems/databases/legacy software code) is far from easy to deal with. Every piece of software has some bad parts (it is what is it). I assume that even people inside Atlassian have mixed feelings about their own product(s) (something similar to this guy: https://www.youtube.com/watch?v=uxC1fPE1QEE )

My critique goes to upper management only, i.e. to Atlassian (company).
Shame on you Atlassian (company)

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.