In today’s post, I will show you how to flexibly limit the possibility of editing tasks and fields to a specific group of users. And there is no need to use any external plugins. We will only use Jira’s built-in mechanisms, such as Security Schemes or Workflow Conditions. Let’s start!
The business need is to limit viewing and editing of tasks to a selected group of people. Additionally, this group should be defined separately for each task in the project. In addition, the Support Team role should have access to all tasks in the project. The solution can be implemented for both Cloud and Server versions, without the need to use external plugins. Below are the elements that we need to configure. Remember that the administrator menu can be called with the gg shortcut.
1. creating a new role named Support Team
- gg -> Project Roles -> Add Project Role
- You can also use one of the existing roles to complete the task
- people in this role will operate the project, so you need to adjust the permissions accordingly (Permission Scheme)
2. creating a new User Picker (multiple users) field named Members
- gg -> Custom fields -> Add custom field
- ultimately, users added to this field will be able to view and edit the given task
- the field can be filled in only by people who are in the role of Support Team in a given project
3. adjusting the Permission Scheme so that all logged in user has the Browse Issues and Edit Issues permissions
- Project Settings -> Permissions (Permission Scheme schould not be shared with other projects)
- remember to give separate permissions for the Support Team role and the jira-administrators group
- the permission will be further limited by the Security Level
4. creating the Issue Security Scheme and Security Level called Edit Issue Restriction
- gg -> Issue Security Schemes -> Add issue security scheme
- in the Security Level configuration, we set the access to tasks only to users who are in the Members field: User custom field value – Members
- we also add Project Role – Support Team and Group – jira-administrators
- we set the created Security Level as default
At this point, each new task will receive a Security Level = Edit Issue Restriction, which allows the tasks to be viewed by the Support Team, Jira administrators and people added to the Members. Note that the field is not present on any screen yet. It’s time for the next part of the configuration. For the purposes of the task, we assume that there is only one issue type in the project and one corresponding workflow.
5. creating a new screen called Modify Members Screen, to which we add the Members field
- the Members field should only be found on the above-mentioned screen, it should be removed from the remaining screens if necessary (create, view, edit screens)
6. modifying the Workflow
- we add a Modify Members transition from In Progress step leading to itself
- we add the Modify Members Screen created earlier to the transition
- check if the Workflow is not shared with other projects
- additionally, if we edit an active workflow, it must still be published after making changes
Now the Members field can only be edited with the just added transition. You should also limit access to it only for people in the role of Support Team.
7. Creating a Workflow Condition of type User is in Project Role and adding Support Team role
- Project settings -> Workflows -> Edit
And that’s it. From now on, the new task will be visible and editable only for the Support Team, Jira administrators and people who are added to the Members field. The Members field can only be filled by using Modify Members transition. In turn, the transition is visible only to people from the Support Team. The solution can be implemented for both the Cloud and Server versions, without the need to use external plugins. Good luck in testing and implementing your solution!
Do you have any questions? Do you want to share your knowledge and experience? Feel free to comment and contact me at email@example.com.