Restricting Permissions between Boards on the same Project

[Michelle Huang]

Hi,

I am setting up a project that my internal team will use, as well as an external party (partner). There will be multiple users that will be using the platform as a part of this partner company. 

I would like a board dedicated to my internal team (and not viewable / accessible by partners), as well as a board that users outside of our organization (partners). This would be different from service desk as our partners would like the power to edit / move around tasks to prioritize. We'd also like to move / clone tickets from this dually accessible board to our internal-only board. What's the best process like in terms of setting this up?

I've also seen on a few other posts that we should be careful around permissioning, since we do not want our partners to be able to see even the individual tickets on our internal board. Could someone please expand upon the restrictions?

Additionally, if it is easier to set up permissioning between multiple projects within the same website / instance, vs boards within the same project, we have flexibility to do this approach, but just want to make sure which one corresponds best with our needs.

Thanks so much in advance!

[Bharath Kumar Kappala]

@Michelle Huang You can try using the issue security, for the ticket which you want to hide from the partners you might want to apply issue security scheme and add only the users who should see the restricted issues to a group and have the issue security scheme tied to that group. 

This approach would help only the users in the security group to view or make changes to the tickets that are restricted, so now you can filter these issues and created a board that way only the users in the Security group will be able to view the board.

Here is some documentation on issue security - https://confluence.atlassian.com/adminjiracloud/configuring-issue-level-security-776636711.html

Hope this helps!!

[Michelle Huang]

Thanks for your quick response.

Would you know if they are also able to create tickets within a project as well (instead of just viewing / editing)? And would we have to then tag every issue that we'd want them to have control over with this specific schema? Just trying to make sure that creating / viewing issues don't have a large overhead since we anticipate it would likely be a lot, and we want to ensure this is the most efficient way to configure our process.

[Bharath Kumar Kappala]

Well Issue Security is security on top of the permission scheme already set for the project. I can give you a example: Lets say you have three issue types in a project called Epic, Task and Story. Your internal team should be able to create all the three issue types and view all of them and edit all of them as well but your partners should only be able to create/edit or view only Tasks and Stories so what you would do it in the permissions give both your internal users and partners permission to create view and edit tickets. 

Now you would start implementing issue security scheme and add only users from Internal group to security scheme.  So when you create a Epic you can select the security scheme restricting Partners from viewing the Epics. The only catch here is partners will also be able to create Epics since they have the create permission, so if you would like to restrict that as well what you could do is place a validator in the Epic create transition that only the Internal user group should be able to create tickets.

If you would like additional help please ping me on my email and I will help you @bhharath1230@gmail.com

[Michelle Huang]

If anyone has any clarity if this would be better structured as project permissioning (making multiple projects vs board permissioning within a project), that would be helpful!