We have hundreds of users and dozens of projects. User management is linked to ldap and all users are part of the jira-users group. jira-users are by default in a role in every project which allows them to browse and create issues.
I have a couple of projects that I want to deny browse and create permission to a small group of users.
Can I do this without modifying every project, while continuing to allow new users to automatically be able to browse and create issues in the target projects?
If I pull the blacklisted out of the jira-users group, then I have to modify every other project to include them explicitly. If I leave them in jira-users then how do I let everyone else browse/create?
It seems like I can't use the project role permissions to do this. So how do I do this?
In the project you want to protect, you need to change the membership such that the people in your "black list" do not get access.
Take the example of "create". The permission scheme probably says something like "Create: role: users", and then you have the group jira-users in the role of users in the project. You need to take jira-users out of the role, replacing it with a group, or set of groups, that does not contain the people on the black list.
I hope your answer will help someone, but with hundreds of users who are sync'd through LDAP, I don't think I can use this answer. In order to not use the group which is sync'd with LDAP, I would have to create a non-sync'd group which will become quickly obsolete.
I need some method which overrides the default permission behavior, some way of making an exception for a small group.
I'm afraid there is no such method. JIRA permissions are permissive and additive - you give people the ability to do stuff, and they then can. Not give them and take away later.
Issue Security is the exception there, as it can hide individual issues from users you've previously granted browse permission to, but it is issue by issue (JIRA users can see all of project XYZ, but I've set a level on XYZ-1267 that says "only admins"). And it has nothing to say about permissions other than "can see issue"
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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