Currently we observed (almost) all existing groups assigned to new users by default. We would prefer it the other way round: a minimal list of groups or groups with minimal permissions by default, that could be extended.
but still I haven't got it. What I now see, I have to differentiate between "Jira permissions" and "Jira groups". Example: all our staff members are "Jira Users" and are in the group "jira-users". Then I have a group "contractors" which shall not see every project. But this group has "Jira users" permission, and it says on the global permission page therefore is also proposed as default membership for new users.
Am I right that I have to remove the "contractors" from the "Jira Users" permission? This would remove the "contractors" from the default group membership, ok. This means I have to assign them the "jira user" role for every project they may see, right? Or can I include them im the jira-user group?
Is there a way to leave the Global Permissions unchanged and pick a set of group memberships as defaults for new users?
Finally it strikes me that being additionally member of a more restricted group actually doesn't harm, however..
Have you looked at project permission schemes yet? It is a way to assign users, groups and roles to a project. I will not be able explain more until my evening hours. Would this example work for you? (If the example works for you, then if other people want to answer at least there is someting more concrete to work with.) If the example does not work for you then please express your needs better.
default new user group will be contract group
Every group can access and create issues in this project
contract group cannot access this project
You have to be really careful about granting group-level access in permissions schemes if you have client confidentiality rules and client-users. The Browse global permission on a scheme that is shared for multiple projects where a group has been granted permissions to that project scheme can cause users to be able to see any project in that scheme. My recommendation is to never grant groups not admins and site-admins project permissions in a scheme unless you've got a lot of time and have really mapped out and tested this thoroughly.
Managing groups can become a pain as only JIRA administrators can add/delete users to them. We always use Roles. The project admin can add/delete users from the roles. Roles are also very useful in restricting who can execute a transition in that project. Most companies don't want to give all users access to all projects. I find having just one group with logon rights and letting the project decide who should have what roles works best. It relieves the JIRA admin from having to manage project access for all the users and projects and cuts administrative overhead. The JIRA admin shouldn't be putting people in groups just on their request. It should come from someone familiar with the project such as the project admin. Just let them add the people to their own project. Simpler.
Sorry for the delay on responding, but I could not get to testing out the steps until now.
A) create two new groups
1) contractor developer group
This group contains only the contractor users
2) contractor user group
This group contains only the contractor users.
NOTE: Do not forget to remove the contractors from the original developer and user groups.
B) create two project permission schemes.
1) Employee only project permission scheme
contains admin group, developer group and user group
2) Employee and Contractor project permission scheme
contains admin group developer group, user group, contractor developer group, contractor user group
C Assign the project permission schemes to the appropriate projects.
The use the contractor user group as the default group for new users.
I think we got it so far. I removed every external from the jira-user group, instead assigned the Jira User Permission to external groups. So I can achieve they see only projects where they have a role. So far so good. Now I want to "use the contractor user group as the default group for new users". Where can I define that? Jira will assign ALL groups with JIRA User permission to new users. If you don't take them out immediately new users see everything. I think this is a bug, or a security leak. It should be none in first place! I should add we don't use an LDAP.
By default new users are assigned to the group(s) with jira-user permission. There isn't a way to change that via the UI. Most people don't use the jira-user group in any permission scheme so new users can't see or do anything. It is only used to give logon rights. People are added to groups or project roles afterward. You could also give the contractor group the logon rights and all new users would be added to the group. Existing users wouldn't be affected. All new users would still be added to jira-users, but if you don't give that group any permissions in projects it won't matter.
This is exactly our observation: new users are by default given membership to ALL groups that have the "JIRA user" Permission, which may be a lot of groups and associated rights, they most likely are not supposed to have. You can only hope to be fast enough to take them out again, before the user reacts to his notification E-Mail. May we turn this question into a feature request, that the administrator shall be prompted for groups when entering new users, or at least set a default somewhere?
The standard practice here is to have a minimal set of "can log in" groups (often, just one) that does little or nothing else (maybe look up user, bulk edit, and access to the "help with Jira" support project)
Most then use roles to control who gets put in where. That really is the most simple approach, and I suspect the response to raising this as a feature request will probably be "use roles"
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events