Permissions to create projects using "Classic" templates

[Angelina Cordaro]

I am creating projects within our clients Jira. We like to use the "Classic" Scrum template but since do not have Jira Admin rights this option is not available to me. My clients IT Director obviously doesn't want to give me Jira Admin rights because I am not their employee and wouldn't want me to have the ability to change anything I so desired.

I am thinking the only solution is to have the IT Director create the Classic Scrum shells and then grant me project admin permissions with manage sprints permissions. Is this correct? I am really concerned that I will not have the ability to change and manage everything within the project. I reviewed the "Permissions Overview" article, and I was a little confused about the permissions a project admin has when updating a "status". Is this referring to issues? 

https://confluence.atlassian.com/cloud/permissions-overview-961266078.html

[Earl McCutcheon · Accepted solution]

Hey Angelina,

You are correct the project admins cannot create or modify any global objects, so a Global Jira Admin (Jira Administrators Group) will need to create the project and workflow for you then you can make modifications as described in the Document you linked.

When it comes to Statuses these too are a global object as they can be used across multiple workflows and other projects where you are not a project admin.  So as a user with Project Admin and Board Admin permissions but not a global administrator cannot modify existing or create new ones on the boards column configuration screen. And add status will show up greyed out on the Board configurations like this:

You can create new Columns and move Statues to the desired columns but you need to contact a global admin to add the statuses.

Regards,
Earl

[Angelina Cordaro]

Hi Earl,

Thank you so much for your confirmation and additional information. So I did move forward with having our client create the "Classic" Scrum projects for us. I was unsure if this was the correct way to go about this but I gave it a go. I instructed our client to create:

1. Our 4 projects in their Jira
2. Create a Group adding our team members
3. Create a custom Permissions Scheme
4. Added all available permissions to the Permissions Scheme (seemed like we needed everything for our project)
5. Connected the Group to the Permissions Scheme
6. Connected the Permissions Scheme to the 4 Projects

It appears to be correct as I can add sprints/issues and access the Project Settings, but I am still not 100% sure.

I did notice that although the group was added to the 4 Projects, the people within the group were not listed under "People" within the Project Settings. So I added the group here as "administrators" (not sure if this is correct). Hopefully, this just identifies our group as "Project administrators" just for this project.

Our client is still concerned that we have access to all of their other projects. After reading other posts in the community, it seems this might be due to the permissions set on our client's other projects such as allowing "Any User" or "jira-software-user".

If you could please provide me your thoughts on this, I would be very grateful. Thank you!

[Earl McCutcheon]

Hello,

It does sounds like they have a the permission schemes across the projects set up to have "Browse Project" permissions set to the default setting of "any logged in user" OR set to a group that all users are a member of via application access, i.e. jira-software-users set for the permission as you noted.

The base permission requirement on a project is the "Browse Project" permission, without this permission the user cannot see the data in the project, and cannot see the project listed in the project menu.

The Process to lock down the other projects would be to set up two groupings of users, one for all access and one for the specific set of users that only needs access to the single project.  Then update all the permission schemes so the Browse project has the all access group associated, and then add in the restricted group to the single project that they need access to. 

Also to take it a step further I would recommend using a Project Role to associate the groups to browse project permission on the scheme so that the scheme can be shared across multiple projects and still maintain a granular way to associate specific groups or users to the permission in the project via the role association, which can be maintained by the project admin.

This process is described in more detail in the following KB article we have on isolating these groups as you are describing:

• How to restrict project access to different isolated user groups

BUT, while the concept of the article still holds true for which settings to change, please do note that the article has a few outdated notations surrounding the Jira Cloud steps as the KB was written before the updates to the Cloud UI and navigation options rework so the menu locations are not correct in the KB at this time, I'm reaching out to our documentation team to get this updated with the current info for navigating the menu structure. 

Regards,
Earl

[Angelina Cordaro]

Wonderful, this is very helpful. Thank you!

[Earl McCutcheon]

Hi Angelina,

I'm Happy I could help, and Just a follow up FYI, the Documentation Update is being tracked here:

• https://jira.atlassian.com/browse/JRASERVER-68463

Regards,
Earl