Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,298,513
Community Members
 
Community Events
165
Community Groups

How to minimize the workload of providing access to Jira projects and Confluence spaces.

Edited

This article has been created in close collaboration with @Ignacio Pulgar whom I am very thankful for all the guidance. Thank you!

Hi Atlassian Community!

When it comes to user management in bigger instances, it is often handed over to Project Administrators for various valid reasons. To be able to hand over this responsibility, Jira admins decide not to use groups for projects and spaces access and instead adding users individually.

In this article we are going to share how to help Project Administrators minimize the effort of individual project and space access.

Why is it better to add users individually instead of using groups?

Before going into the solution for the work minimization of the individual access of projects and spaces, we should answer why this approach is considered better.

Users can be provided with Project Administrator permission therefore they can grant access to Jira projects and don’t rely on Site Admins. The same can be done for Confluence spaces by granting users with Admin permission.

Transparency

Since users are not able to view who belongs to which group, Project Administrators can’t identify who already has access to the project or if users who shouldn't be able to access it are indeed granted the access.

In this situation Site Admins often get requests to give access to users who can already view the project/space.

Thanks to the transparent approach, by giving individual access, Project Administrators can easily control user’s access and protect the sensitive data.

Dependency

In the situation when Site Admins are not available or their queues are extremely long, space and project access would be blocked.

By transferring the responsibility to Project Administrators we are removing the bottlenecks and are able to provide faster support for new project joiners.

Thanks to moving this responsibility from Site Admins, they are able to provide faster support for the tasks that they are the only people who can support it and focus on on the tasks that can bring the most value to the project/spaces and instance.

 

The article created by @Ignacio Pulgar  covers this topic in more detail - What is the best way to provide access to projects and spaces?

Minimizing access workload

There are several methods for reducing the administrative workload of managing project and space access.

Minimizing Jira project access workload

Merging existing Jira projects

If the projects managed by the same person are accessible to the same or similar group of users, it is a good idea to merge them it one project. To recognize different workload within the merged project we suggest using native Components field.

A bulk move operation will help moving the issues to a single project, as well as setting the appropriate Component.

Even if just one team should have access to all issues in a given project, while another set of users should only have access to their own issues, it is still possible to set a solution for having that requirement met using a single Jira project.

Also note that filters, boards or dashboards can be created to display different sets of issues from the very same project, therefore having separated views with no need for using multiple projects.

Creation of new projects

To minimize the effort even more, ask yourself if the new project can be avoided and managed in already existing one. That way Project Administrator have to manage access only for one project instead of multiple ones.

Minimizing Confluence space access workload

It is also a good idea to reduce the number of spaces managed by one person if multiple spaces need to be accessed by the very same set of users, or by a very similar one.

If it is possible, simply merge existing spaces and create new sections instead of creating new spaces, in one Confluence space.

To restrict access to some of the pages to selected users, you can use Page Restrictions.

Future possibilities

Atlassian Teams

Atlassian has developed a relatively new feature for users to be able to manage Atlassian teams.

The possibility of using these Teams in the project and space access management will be revolutionary, making it much painless and user friendly for Project Administrators.

Jira - Confluence integration

Some time ago, there was a suggestion of a new feature for Atlassian to help better integrate permission between Jira projects and theirs linked Confluence spaces - Delegation of space access permissions to its linked Jira projects.

This feature would reduce the administrative workload of dealing with project and space access, although it is uncertain if Atlassian will add this feature to their backlog.

 

What are your thoughts on this topic?

Are you for or against merging some of the projects and spaces into one?

Or maybe you have another idea how to minimize the effort of managing projects/spaces access?

We would love to hear your feedback on this subject!

1 comment

It sounds like the root cause of the problem you describe is that groups in such a configuration are not understandable and transparent.  At our company, groups come from our AD and are clear in description and visible in population in the other shared applications (Outlook, Sharepoint, etc.)  Our primary groups are by reporting structure, which then matches the general use case for Jira and Confluence.  If you see "Group John Dunkelberg" has a Developer role in the project, anyone in our company can easily know that means people reporting to me.  Then we don't need to do the wasteful effort of adding and removing individuals when they join the company, leave the company, or transfer between teams.

I do agree that linking Jira and Confluence permissions would be great and would reduce waste.  In general it's disappointing that Atlassian hasn't tied these flagship products together better.

Like Ignacio Pulgar likes this
Ignacio Pulgar Community Leader Mar 30, 2022

Hi @John Dunkelberg ,

Thanks for your feedback!

It is an interesting approach having AD groups with people names on them, based on who reports to who.

I'm just thinking: Atlassian User Groups names cannot be edited once created... How is that solved when a user to which other people report is substituted by another person who is assuming that role?

Thanks and regards

@Ignacio Pulgar - when management structure changes (a relatively rare event) then the old group will need to be replaced with the new group.  Our Jira admin team has developed scripts to find all instances of a particular group to aid in this.  Fortunately we're not the kind of company that does frequent re-orgs (compared to a previous employer that seemed to re-org every year prior to the end of the FY)

Like Ignacio Pulgar likes this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,866 views 37 49
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you