I'm running a JIRA instance where the application users group is set up as per default, and everyone has access to everything within the organization.
Now there is a need to introduce a new group of users that should only have access to some projects.
How best to deal with this?
Try adding a permission schema based on project roles. This can be applicable across different projects.
Create a new user group and add the members you want.
Let's say
Role "Core Team"
Configure permission schema that "Core Team" has:
For "Project 1" , go to Users and roles and add "New_Group" under "Core Team" project role.
This would ensure that all members of "New_Group" have the permissions assigned above.
OK, yes, but if every member of the New_Group must also be a member of the jira-users-group in order to be logged into the instance, every member of the New_Group will have the permissions given to the jira-users-group: they will be able to see every other project, which is what I want to prevent.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That is a different case, but easily solvable.
First of all setting up permissions for Application Access Groups (i.e jira-users-group), imo is definitely wrong. Please revise that.
Second, for you exact scenario, go to JIRA -> Applications -> Applications Access and add "New_Group" under JIRA Software or Core, depending on what you're using.
This way members of this group will also have access to JIRA, but by not being members of jira-users-group.
Don't worry about duplicate. JIRA doesn't count duplicate or disabled users towards the license limit.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
OK, thanks!
Why do you think that the application acess as set up per default by Atlassian for the jira-users-group are wrong?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Application Access is OK. Though in case of multiple, well even few, users - my suggestion is to go by groups, example
JIRA_Users_Dep1
JIRA_Users_Dep2
,etc
and give Application Access to that group.
What I'm saying is that you should not configure permissions based on jira-users-group.
jira-users-group should not be able to see every project. Specific cases of public instances might be ok, but even than some restrictions are required.
Instead a better approach is using Project Roles. That's it's purpose.
jira-users-group should be able to view only public projects, even than the permission is set to Any logged in user and not the group specifically.
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
You have to create user group and add them to the project.
Check the below link,
https://confluence.atlassian.com/adminjiraserver071/managing-groups-802592332.html
-Praveen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
OK, but should this group be a sub-group of jira-software-users group? If it is, then the members of this sub-group have automatically access to all other projects, which is what I want to prevent. These are the default permissions of the jira-software-users group listed in the documentation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
You can check the below link for instructions. The user has the exact same request.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.