You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
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.
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?
There are several methods for reducing the administrative workload of managing project and space access.
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.
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.
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.
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.
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!