Managing Users and Groups

JIRA Studio Documentation

Glossary
Index

On this page:

Users and Groups in JIRA Studio are managed by JIRA. That is, the users and groups set up in JIRA will be inherited across all the applications in JIRA Studio. However, please note that default groups for JIRA Studio differ from JIRA, as follows:

JIRA Studio's default groups

When you install JIRA Studio, three groups are automatically created:

  • users — should contain every JIRA Studio user in your system. By default, this group:
    • has the 'JIRA Users' and 'Bulk Change' global permissions in JIRA. 'JIRA Users' allows users to log in to JIRA, and and 'Bulk Change' allows users to bulk edit issues.
    • is a member of the 'Users' project role in JIRA, which allows members to see all project issues (unless protected by a security level) and create new issues.
    • has permission to create and view Confluence (wiki) content for the project.
    • has read only access to Subversion.
  • developers — typically contains people who perform work on issues. By default, this group:
    • is a member of the 'Developers' project role in JIRA, allowing developers to edit, move, assign, be assigned, link, work on, resolve and close issues.
    • has the 'Browse Users', 'Create Shared Filter' and 'Manage Group Filter Subscriptions' global permissions in JIRA.
    • has the 'Personal Space' Confluence permissions only.
    • has read/write access to Subversion.
  • administrators — typically contains people who are JIRA Studio administrators. By default, this group:
    • is a member of the 'Administrators' project role in JIRA, able to edit project versions and manage project content (delete issues, comments, manage watchers).
    • has the 'JIRA Administrators' global permissions in JIRA.
    • has the 'Attach Files to User Profile', 'Personal Space', 'Create Space' and 'Confluence Administrator' Confluence permissions.
    • has read/write access to Subversion.

Users will typically belong to more than one group, ie. users only, or users and developers, or users, developers and administrators.
By default new users will be added to the users group (the only group granted the 'JIRA Users' global permission).

To manage users,

Instructions on managing users in JIRA can be found here.

To manage groups,

Instructions on managing groups in JIRA can be found here.

While user groups are managed by JIRA, Subversion permissions are assigned to user groups via the Subversion Repository Manager. Instructions on managing Subversion permissions can be found here.

User Types in JIRA Studio

Users are also assigned a User Type in JIRA Studio, for license purposes only. For further information on User Types, please read the JIRA Studio Licensing page.

To manage user types for users,

Instructions on managing user types for users can be found here.

Restricting project visibility

Studio's default permissions assume just one set of users who have read access to everything ("users"), and groups who have varying permissions beyond this ("developers", "administrators").

If some users should not be able to see certain projects, then you will need to:

  • Create groups for each separate set of users, eg. a group per company, or perhaps a group for each project.
  • Edit JIRA role memberships, Confluence space permissions and Subversion permissions to use the new groups instead of the old groups.

For instance, say there are some contractors who should only be able to view a particular project. In this case it makes sense to split users by company, so by creating two new groups, eg. mycompany-users and contractors. Then redesign the permissions in each application:

  • In JIRA, we want to make most projects visible only to mycompany-users, and one project visible to mycompany-users and contractors. For each project listed in the administration section, click the project name, find the Project Roles: section and click "View members" and edit the "Users" role groups.
  • In Confluence (the 'wiki' tab), go through the spaces one by one. Click the "Brows" dropdown arrow, pick "Space Admin", and then click "Permissions" to show the space permissions. You will see the "users" group has view permissions. Grant the mycompany-users group the same permissions, then delete the users group entry. For the relevant project, also grant the contractors group view permissions.
  • Click Administration -> SVN Permissions to adjust Subversion and Fisheye permissions. Go through the projects replacing instances of the users group with mycompany-users, and in the relevant project, contractors.

New users get automatically added to whichever groups have the 'JIRA Users' global JIRA permission (under Administration -> JIRA Permissions). By default only the users group is set, which means that under the new permissions, new users won't be able to see any projects by default. If you want newly created users to be assumed to be company employees, add the mycompany-users group to the 'JIRA Users' global permission.

Managing Anonymous Access in JIRA Studio

Anonymous access in JIRA Studio can only be enabled for JIRA and Confluence at this stage. If you wish to enable anonymous access for these applications, you will need to configure each application individually as follows:

To allow anonymous access in JIRA,

Grant the 'Browse Projects' permission to 'Anyone'. Instructions on changing project permissions in JIRA can be found here.

To allow anonymous access in Confluence,

Change the space permissions for your project to allow anonymous view access to your project's wiki. Instructions on setting up anonymous access in Confluence can be found here.

To allow anonymous access in Subversion,

Anonymous access to your project repository is disabled by default. Enabling/disabling anonymous access to your repository is restricted in JIRA Studio. Read more about Enabling Anonymous Access to the Repository.

Labels

administration administration Delete
user user Delete
security security Delete
group group Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.