"... Can we make the stories visible only for the developers? ... " or "... colleagues from the specialist department should only be able to create tasks ..." are questions or tasks that we are often asked in our daily work in the care of Jira.
Now Jira does have a sophisticated authorization system with high structural depth, but with such requests often even experienced Jira admins reach the limits of the configuration possibilities. But Jira offers a rather rarely used functionality that we want to look at today: "Issue Security" or "Vorgangssicherheit".
Often when setting up new projects, process security is not configured. This is probably due to two things:
The setup of the process security is not included in the template projects and must be set up manually at least initially.
With transaction security you effectively get an additional level in the authorization system of Jira, which often leads to confusion for users even in the basic setup.
At the same time, this functionality is very powerful and can (if configured correctly) cover some complex use cases that would not be possible otherwise. Therefore, we have gathered 5 of these examples to present them here:
1. archive outdated content without distorting statistics
Archiving operations is a feature of Jira on Data Center. With the setup of a Process security project administrators (or any other desired role, group or user) can easily specify in the task whether it should be "archived", mimicking archiving of individual tasks even on Server or cloud instances.
In this case, the process is hidden from the normal users. Admin users can still see the operations. This also ensures that evaluations for admin users are not distorted, while normal users see less content that is already irrelevant.
The function to "genuinely" archive individual processes has so far only been reserved for Data Center installations. However, other side effects must be taken into account:
2. hide content from external users
It is certainly possible to share entire projects with a group of users or to hide them. However, there is often also the desire to hide only individual contents of a project for a group of users.
For example, in a project, new stories could be available only to internal employees be visible, while external employees can still see bugs and tasks.
3. work on IT security topics without making them publicly available
If the entire IT works in Jira and documents its tasks there, why not the IT security team as well? The problem is that the team needs the support of other teams, but at the same time the IT security topics should not be easily readable for all employees of the organization.
For this case, the process security could be configured in such a way that only those users can see corresponding processes that have been explicitly entered in a field by an admin.
4. evaluations for developers without business tasks
Cross-functional teams are becoming increasingly important, especially in agile setups. However, evaluations can often lead to confusion if, for example, all development tasks have been completed on time, but there are still open business tasks. In these cases, the goals or the KPI's can therefore not be achieved.
Business tasks could be made invisible to developers by configuring the task security. Such tasks would also no longer be visible in evaluations or lists.
5. visibility of orders only for certain locations.
As already mentioned in our previous blog (Process optimization in scheduling) described, delivery orders can also be managed centrally in a project without individual orders being visible across the boundaries of the respective location.
This way, a central team can see and edit all jobs in a project, while users from dedicated locations can only see those jobs that are also assigned to them or their location.
There are certainly plenty of other or similar use cases for process security. Hopefully, the above examples show what possibilities there are to take advantage of a common Jira project without overwhelming the individual user with a possible flood of content.
In order to best possible results and meet the needs of teams in Jira, operation security should not be overlooked, but should be available as an additional tool to a Jira administrator's toolbox.
Depending on the complexity of the process security, a well thought-out role concept can be helpful or at least supportive. However, due to the flexibility of the configuration (according to roles, groups or users), it is not absolutely necessary.
We at Swarmit have already put these and other similar setups into productive use several times at various customers and are happy to assist in the design and implementation of process security for Jira projects.
Erik Neudert, Swarmit AG