There are several projects as well within my board. I only want this group of users to be able to access one board in one project. What steps will I need to take?
1. creating a group
2. assigning users to that group
2. creating a permission scheme
3. assigning permission scheme to group
4. Editing board settings's shares to include that group
You should separate out boards and projects in your thinking first. Boards do not contain projects, and projects do not contain boards. A project is a collection of issues, and a board is a view of a set of issues, determined by a search.
You've got some steps here right - a new group is a good way to start off, and then using it to share the board is correct. Then looking at the permission scheme is the next thing to do.
However, you can't "assign a permission scheme to a group". A permission scheme tells a project who can do what within it.
To get your setup to work, make sure your group has "browse project" in the permission scheme, and associate that permission scheme with the one project that you want them to see the issues of. Then, go back over your other projects and make sure the users in the group do NOT have browse permissions for them.
This will do what I think you want, because the boards will only show users issues that they can see. So if you have a board that says "project in (a, b, c)" and your new group can only see project b, then the board will only show them issues from project b.
Thank you very much for your response.
I understand that a permission scheme is a set of permissions for a project, but it does seem there is some level of granularity that can be achieved if you can grant permissions within a project to a group. Granted I suppose is a more correct term than assigned then.
Just to be clear though, I'd need to create a new project in order to manage visibility in the way I want, right?
What exactly is shares then. I thought that might be what I need. If I only share that one board with that one group, I was hoping that would allow me to limit visibility to a set of issues (a board) within a project.
Yes, the permissions are all about the granularity of "who can do what".
You can use simple groups in them, but that could mean needing a scheme for every project. If you use roles instead, then you can re-use the scheme, and delegate the "who can use the project" to the project administrators.
Imagine you have a role of "project users", and you have a permission scheme that says "Browse: role of project users". Now imagine you have that permission scheme in projects A, B, C, D and E. You or your project leads can now add the group "External users" to the "project users" role in project B, and they will be able to see issues from B, but not A, C, D or E
Yes, it probably is easier to create a new project so you can separate your users up like this. The other option is to get clever with "issue security", which lets you hide individual issues, but then you are into setting up workflows that set security for you, and/or relying on users to get it right (or not get wrong)
Shares of boards are shares of the whole board. It is independent of the project and issue visibility, but you'll want to make the board shared for the users, then the projects behind it will filter through (assuming they can see the projects and issues)
We’re excited to invite you to this action-packed webinar where we will demonstrate how to integrate Opsgenie’s powerful alerting and on-call management tools with your entire Atlassian stack. Mar...
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!
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