...
| Include Page | ||||
|---|---|---|---|---|
|
Topics
| Table of Contents | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Introduction
This page outlines the level of permissions exists to restrict access to the App and its functionality. But also additional permissions App create to let non-admin access to some Jira functionality, thus letting admins delegate some controls to individuals.
Restricting Access to the App
There are three levels of Apps permissions, namely
Global Permissions,
Board Administration,
Board Manage & Readonly Permissions.
Global Permissions
Global App Permissions
Global permissions are created automatically when installing the App. There is ongoing issue with Atlassian when on some sporadic cases Global permissions are not properly populated. In this cases, no one can access the App and Jira Global Administrators need to configure it manually.
If you do not see the App in Apps menu please contact your Jira Global Administrators to configure Global permissions manually to add you or/and group you are part of to the settings.
Board Creation Permissions
| Info |
|---|
Coming soon |
Global permissions are good to decide who can view/access the application. But once you can view/access you can create any Release Board with Projects that are available to you in order to manage releases. Some companies want to restrict such flexibility to have a limits subset of approved release boards. Therefore, we created a special permission - [Release Management - New Release Board Creation] - that allows to specify users/groups that could create boards in Application.
Board Administration Permissions
Board Administrators are able to manage the board and change its configuration. It is possible to add a number of Administrators to the board by mixing individual users and groups.
Global Jira Administrators have administrative access to each release board by default. It doesn't matter if they are explicitly added to the board as Administrators, or not.
The Board Administrators can delete themselves from the list unless there is at least one active Administrator remaining in the list. If user tries to delete the last remaining Administrator of the list the warning message will appear preventing this action to happen.
...
🆕 Board Manage & Readonly Permissions
Manage & Readonly board permissions are granted by using the "Permissions" section of board configuration. Board Administrators and global Jira Administrators have board manage permissions by default.
If the user has Manage & Readonly board permission but does not have Browse Project permission - versions from those projects will not be shown on the board. In that case, the user will see a warning next to the board name:
...
The difference between Manage & Readonly board permissions is the following:
Manage means you can manipulate versions, packages, environments, release notes templates on the board (aka creating, changing, add/remove scope, deleting, archiving)
Readonly means you can only view versions/packages on the board without ability to process them thru the workflow, change scope, assign environments, etc. But you can generate release notes using existing templates, view environments the versions deployed to, get insightful reports, etc.
There are three way to assign Jira Users Manage, Readonly permissions
...
Users of projects in board
This option grants Board Manage, Readonly permission to all users who have permission to view projects added to the board.
Users of projects
Board Manage, Readonly permission is granted to all users who have permissions to browse selected projects.
Users and groups
Board Manage, Readonly permission is granted to specified Jira Users and groups.
Permissions for Non-Admins
| Info |
|---|
Some functionality in Jira - like creating/editing Versions and Releases - available only Jira/Project Admins. This is not very flexible when you have multiple teams ns projects and you run cross-project release management or need to sync components cross project. Therefore, we introduced 2 additional permissions, namely:
to let non-Admins to create/edit versions and components. This gives admins a bit more flexibility to delegate this function to certain groups and unlock engineering teams on their execution. |
Versions/Releases Management Permissions
To let non-admins create / edit releases in Jira (delegate this role to certain group of people) you need to navigate to Project Settings
...
You can either change the default schema or create an “escalated“ one (recommended).
Click Action\Edit Permissions.
...
Scroll to find [Release Management - Project Versions Management] and click Update
...
Now you can assign this permission to either individual, role or group …
...
Click Save.
| Note |
|---|
Note: the above applies only to Release Management App you still can’t create/edit release using Jira standard functionality of you are not project admin. |
Classic Components Management Permissions
In Jira by default Components belong to Projects and could be managed by Project Admins only. This overcomplicates cross-project component management. Therefore, most of the Partner Apps that have a functionality for cross-project component management are making all the changes in App-context allowing to override Project Admin permissions.
To give Jira Global Administrators control over it we created a special permission - [Release Management - Global Classic Component Management] - that allows to specify users/groups that could change Components from Release Management w/o being Admin for corresponding Jira Projects. The scope of such permission applies only to the projects listed for the board.
| Note |
|---|
Note: the above applies only to Release Management App you still can’t create/edit components using Jira standard functionality of you are not project admin. |
| Include Page | ||||
|---|---|---|---|---|
|