tags:

views:

934

answers:

4

Currently we have mutiple projects sharing a JIRA instances. We want to make it such that the users only view the projects that they are doing testing.

But however we are currently groupging these users to the standard grouping jira-users.

What is the best way to filter out JIRA project that only certain users can see and access

+2  A: 

You should create special Groups of users for each project you have... you can have more than one group, something like "project1_developers", "project2_observers" for better organization.

You alson combine these groups with the Project Roles to define into each project what kind of access each group should have.

Make a Permission Scheme to set of permissions to one project. Something like this:
Browse Projects -> Group (project1_admins, project1_developers, project1_users, project1_observers)
Create Issues -> Group (project1_admins, project1_developers, project1_users)
Move Issues -> Group (project1_admins)

You can use your Project Roles here too... but I prefer to set everything with groups.

Finally, you can use Issue security schemes to define who can and cannot view issues. Issue security schemes implement a number of security levels which can have users/groups assigned to them.

Hope that can help.

Skubs
A: 

Personally I'm all for project roles. I have a general permission scheme that allows all users/groups defined in project roles to browse the project, which leaves the project administrator/manager to define which groups can view their project. So by removing or adding jira-users (default group that a user would have to be a part of to even log into JIRA) to thier project's "users" project role, the project manager can control if all users can view their project or not.

Brian
A: 

The best and dynamic way of solving this problem is with the help of security levels and setting the security levels based on the issue at run time using a post function.

Balarami Reddy
A: 

Totally agree with Brian: Project Roles are the way to go, else you end up with too many Groups. Role membership is local to a project. Groups are global.

Totally disagree with Balarami: security levels should be used very sparingly and on small percentage of the issues (on exception basis).

Vladimir Alexiev