Application Administration? Project Administrator? Please help

Hi all, I would like someone to help me understand the Admin levels in JIRA...I Think I am missing "Project Administrator"? (*See attached image) At our company there are two of us who are System Admins, How ever we have four "Solution Builders/Project Managers" and we require them to have a level of access where they can take control of project functions, These people are generally the "Project Lead"....However we do not want them to have access to the schemes (Permission/Notification), workflows, fields and screens...if that makes sense? So looking at the image(attached) I got when I was attending a JIRA Webinar this year, I see "Project Administrator" But do not see this in my Global Permissions, Where I do see System and Jira Administrators? Am I missing something? Could someone explain? Thanks, Warren

6 answers

1 accepted

4 votes

There are four levels of user in Jira

  1. System admins - can edit ALL the system and Jira settings - specifically the stuff that is global and heavy - indexing, attachment paths, localisation, these guys can take the whole thing out. In Unix terms, they're "root" (and have all the rights of "Jira admins" below)
  2. Jira Admins - can edit Jira settings, schemes, project settings (i.e. what schemes a project uses), user accounts, groups and so-on
  3. Project Admins - can edit a project, changing versions, components and the users within the project (and Greenhopper boards if you've got that installed)
  4. Users - well, they're users.

How they get these rights:

  • Users - they have an account
  • Jira and System administrators - are in groups defined in Global Permissions
  • Project Admins - are people who are given "project administration" by the projects permission scheme - this can be quite granular - you can end up with someone who is a project admin in ONE project. Note that Jira and System Administrators do NOT get this right automatically, you still have to include them in the permission scheme! (Some sites define a group of project admins and use that in the permission schemes, or directly include the admin groups in the permissions)

Sounds to me like you need to put your solution builders into project admins permissions. Might make sense to do this with a group and use that group in the permission schemes

2 votes

As I just said, project administrator is done in the permission scheme for the project. It's not global.

Project Lead is a field that says "this person is the lead on the project". A common thing to do is say (in the project permission scheme, of course) "project lead has project admin rights", but it is optional

Oh i see, If I were to create a group call Project admins, Would the "Administer Projects - Ability to administer a project in JIRA." be the correct permission to add this group to? So that they have this "Project Administrator" status?

Yes, you'll need add the permission in all of your permission schemes if you want it to be global though.

Who would then typically be the Project lead? Where would all the issues with "Automatic" Assignee's go to? Currently Project lead would get them?

The project lead is the project lead, I'm not sure how else to put it.

You name someone as the project lead. They are responsible for the project. You can use that flag in other places so that when a project lead changes (Dave leaves, Bob takes over), you don't have to go through and change it, you just change the project lead. You can use project lead in the automatic assigne stuff, permission schemes and notification schemes, and some other places.

The fact that you let other people administrate the project has nothing to do with project lead, it's a permission to let people admin the project.

Damm....this is so hard? So we have 4 Project admins/solution builders and currently they are project leads in the various 300 odd projects we have, but currently myself and a colleague are system admins and do not want the project leads to have any access to the permission/notification schemes, just in the off chance they may alter something by accident we would prefer them not to have the access to do this? So i thought of putting them in the "Project admin role" which would sort that problem out, but then i'm faced with another...which is the project lead issue? If i make them project admins and remove them from project leads, who will then be put into the project lead position to take care of all "-automatic-" assigned issues? Do you understand what i'm trying to say Nic? Can you give me your thoughts on this?

I'm not sure why this is so hard. I know there's a lot of it, but I don't know why you keep going back and muddling up permission layers and simple fields.

Each permission is separate.

As I said already, you've got System Admin rights and Jira admin rights. That is controlled by global permissions. You don't want these people to have these rights. So make sure you don't put them in an groups that give them the rights.

Project lead is NOT a permission. It's a field that names a user as the owner of a project. You can use project lead in other places to say "Jira, when you need to send email/use permissions/auto-assign issuess/use workflows, then look up who is currently the project lead and use their account"

In your permission schemes, there is a "project admin" permission. You can include project leads in this if you want, or a specific group, or a role, or other things.

No I understand this, however I want the project managers/solution builders in the "Project admin role + Project admin permission" as this is where they belong and the level of access will be perfect for them, however i then remove them from the project lead field and not sure who will fill this position as I do not want the project managers/solution builder to have any access to the permission/notification schemes?

Again, the project admin permission does NOT give the users access to permission or notification schemes. They only get version, component and user maintenance.

Project Lead does not have to be filled at all. If you leave it empty, you can't take advantage of the automatic assignment by component stuff, but it really does not have to be anyone. In a lot of development projects, we actually set it to either the person doing the triage, or the lead developer - not necessarily the project owner, but the person who will be doing the initial allocation of work!

http://imgur.com/Hs0llO2 (Image url, Couldn't find attach image)
Hi Warren, we need to add the members who wants to control the project details by default in the Project Administrator role in the Roles section. If we add them in the Project Administrator role, they can Administer the projects but cant have access on the permission and schemas
Where would I find this "Project Administrator role" Global permissions?
What is the difference between the Project Administrator and Project lead?
Who would then typically be the Project lead? Where would all the issues with "Automatic" Assignee's go to? Currently Project lead would get them?

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

257 views 4 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you