We have an installation of JIRA that is hosted and managed by our IT staff. It is used by a large number of unrelated projects, each with different requirements for security and notification options. Our IT staff is able to support the creation of new projects, but since there are so many existing projects they cannot manage individual permissions and notification schemes for each.
Is there a way to allow project administrators (or at least the project lead) to control a project's permissions and notification settings without requiring JIRA administration access? This would seem to be a logical role for a project administrator anyway, rather than the JIRA server administrator. Top-level schemes are helpful as templates, but I don't think they should be the only way to configure an individual project's settings.
No.
Project admins can amend users, components and versions. That's it.
You probably want to have a quick read through https://jira.atlassian.com/browse/JRA-3156 and vote on it! (Please? It's really needed for, well, everyone I've ever worked with. It's #3 on my list of things Atlassian need to fix, so every vote is welcome!)
I added my vote, but it doesn't really look promising seeing as this issue has been outstanding since 2004 and the last Atlassian comment was in 2007, which is very discouraging. This is a pretty standard common-sense feature that I would absolutely expect from any product that's been around as long as JIRA has and has had as many major releases. If they expect JIRA to work in any corporate or enterprise environment this feature is an absolute must.
Generally speaking, I've been largely impressed with Atlassian's products, but the lack of foresight for this issue and the lack of response of any kind, especially after they claimed that they intended to implement it all the way back in 2004, is extremely disappointing. Shame on them for not making this a priority.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yup, I can't argue with that. I've worked with Jira for many years, and there's obviously a huge gap between "project admin" and "system admin" that needs fixing.
If it's any encouragement, Atlassian *do* revisit old issues and fix them. Sometimes. I've been whinging about "can't rename options in select list" for years, and that got done (albeit by an employee being nice instead of the design-flaw-fix it should have been), and https://jira.atlassian.com/browse/JRA-9 probably holds the record - a shade under a decade to fix it, but they got there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Do you have Confluence?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, we don't have Confluence. From what I understand it's just a wiki tool right?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes. The only reason I asked is that there are some JIRA self service options available using Confluence and Confluence CLI Plugin . I am looking into something similar for JIRA for those who don't have Confluence.
I would just add that we use roles for our Permissions which give the project administrator a lot of control access permissions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I just released the plugin that we use internally for this purpose. Works for me on Jira 5.2. Your mileage may vary(ie. test etc :) ) - works pretty well for us. https://bitbucket.org/dwester_turner/jira-projectadmin . Note the requirements that your notification and permission schemes must contain your project key (space delimited).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That is a good one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A mild relief on this front is the right usage of Project roles by using the project roles in Notification and Permission Schemes. And the project administrator can decide who belongs which all roles. This does not satisfy the needs completely, but reduces the pain.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, this is what we're doing now but it requires that the system admin setup the scheme with all the permission and notification rules for each project role. If we want to make a change to that - add or remove permissions for a given role for instance - we have to have a system admin do that. This works when there are one or two projects in the JIRA installation but it's not scalable for use across a company.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.