Welcome to this Atlassian University Skillbuilder on configuring and troubleshooting

permissions in Jira.

This training has been designed to sharpen your skills when it comes to setting up or
troubleshooting and fixing complex permission-related configurations in Jira.
To succeed in this training and understand the use cases presented here you'll need the
following
• End-user experience with Jira to understand users’ requirements and their problems
• Administration experience with Jira to translate requirements and problems into
configurations
• Familiarity with foundational Jira concepts of projects, issues, issue types and related
configurations
• And finally a deep understanding of project schemes and their instance-wide
counterparts such as application access
And here is what you will learn here:
• We will cover the basics by re-iterating the foundational concepts and the terminology
of permissions in Jira.
• We will quickly get to the point where we need to identify related configuration
elements, since permission-related configurations and configuration changes cannot
be evaluated without analyzing their context.
• After this baseline, we'll start exploring real-world use cases.
• We'll start from a conceptual perspective, to answer the question: “How should I
implement this requirement?” then we'll move along into a problem-solving and
troubleshooting mode to help you understand the various factors that need to be
considered when ”fixing” a potential problem.
• The use cases will be enriched with best-practice advice to provide some guidance to
help you work more effectively.

The training was developed based on Jira Software Server but most of the concepts and
challenges are directly applicable or very similar with other Jira platforms and
applications.
We'll cover these areas:

• First we'll set the stage by looking at a very simple use case.
• Next we'll refresh your memory of the basics and provide enough background
knowledge for you to be able to master the subsequent two modules which are the
heart of this course:
• The configuration use cases module will provide a baseline and a common approach
to follow when it comes to meeting configuration requirements.
• The troubleshooting use cases module will shine a light on common problems users
and administrators encounter related to permissions and (mis-) configurations.
Updating a configuration based on new or changing requirements, and fixing a potential
problem, can be the same thing.
It always depends on whether the current setup “works as designed”.
The design itself is always subject to change, but ultimately what is being asked of you is
to decide how to implement a Jira configuration change. The tricky part is: Most likely
there is no single answer or a single valid approach.

Let’s have a brief look at the use case presented here: Apparently many people have the
permission or permissions needed to rank issues. Whether this was by design or not
doesn’t matter. Now it’s up to you to restrict the ability to only certain users: the product
owners and the scrum master. Sounds like an easy fix! Well, is it?
Consider these factors:
- Would you use groups, roles or individual users?
- Is the permission scheme shared?
- Does the backlog contain stories from multiple projects?
- Are the scrum master and product owners responsible for multiple projects?
- Who should be able to manage your configuration in the future?

Let’s have a look at another use case.

A user cannot see a queue in a Service desk project.

Does he see the project at all? Does he have a valid license?

Probably he is not acting as an agent in that project. But is that assumption correct?

In order to answer that question we need to analyze many things, from application
access to project permissions.
Let’s go back one step and have a look at this really simple use case that everyone has
likely seen in the past.
“A user needs to assign an issue to another user and leave a mention while doing this. “
For now, we want to keep it that simple.
Let’s see which “configuration elements” are involved!
Of course, permissions are going to be a relevant configuration element here.
Let’s focus on Alana. As a start she will need the Assign Issues permission in order to
perform the action of re-assigning issues.

How does she get that permission?

Permissions are managed in schemes and granted to users in various ways – from
individual assignments to granting permissions to groups or project roles. The specific
implementation will depend on many factors such as company guidelines.

Going back to our use case, we quickly identify that Alana will need another permission:
The Browse Projects permission. Clearly, you need to be able to see the issue you want to
re-assign. This permission controls who has general access to a project and the issues in
a project.
This brings us to the next element which connects the dots between the configuration
and the user Alana: the project.
A project is configured in schemes and the permission scheme is just one out of many.
For now we ignore issue security, screens or workflows but they might all need to be
analyzed to tackle more complex use cases which we will do later in this training.
Let’s not forget about the global settings such as global permissions. As the name
states, they are global and apply to all projects.
In our use case we have to make sure that Alana has the global permission to Browse
Users. Otherwise she will not be able to mention anyone.
Speaking of global, the basic question to ask is: Does Alana have application access?
Does she have a valid license in the appropriate application?
In some use cases application access is the determining factor for what users will be
able to do in Jira. A prominent example would be specific Jira Service Desk-related
functions that are only available for users with a valid agent license.
Combining all elements we can see that the simple use case isn‘t that simple after all,
and many configuration elements have to be taken into consideration.
The bottom line is that Alana needs application access, and also the Browse Projects and
Assign Issues permission, in the permission scheme which is associated with the DEV
project.

Why is this only almost the complete picture?

Well, are we using groups or roles in the specific scheme? Is the scheme shared? Will
adding her to a role actually grant her more permissions than she actually needs? Will
this cause a security issue?
We will go through these questions once we deep-dive into other use cases.
Now let’s review the basic configuration elements that we'll reference throughout the
entire training, to get everyone on the same page.
The main concepts of Jira permissions revolve around Application Access, Global
Permissions and Permission Schemes.
• Users need application access to log in and use the features of a particular Jira
product - Jira Software, Jira Core, and Jira Service Desk.
• Global Permissions control system-wide functionality, and are only granted to groups
of users.
• Project-level permissions on the other hand are managed in permission schemes that
specify what users can do in particular projects.
• Last but not least, this module will revisit certain configuration elements that have to
be considered most of the time, when dealing with permission issues.
 In order for a user to log in and access a Jira product (such as Jira Software, Jira Core, or
Jira Service Desk), they must have application access.

This access is obtained by being a member of a group that is assigned to a Jira

application. When Jira administrators create a new user, they specify which Jira
application(s) the user will be using, or they just accept the default group for that
application. The user will then automatically be added to the default group(s) associated
with the application(s). Groups are used to specify application access, rather than
granting users access to applications individually, in order to make administration at
scale easier.
Default groups are automatically set up for each application - jira-core-users for Jira
Core, jira-software-users for Jira Software, and Jira-servicedesk-users for Jira Service Desk
- as you can see on this slide. The default groups, however, might be different in your
organization!

Each application comes with unique features that are available only for users with
access to the specific application.
This is why troubleshooting might start right here!
- If users can’t create or view boards? à They probably don’t have a Jira Software
license

18 - Project Administration in Jira Server

 - If users can’t manage a queue or transition issues in a Jira Service Desk
project à You need to understand if they have a Jira Service Desk agent
license.

18-<Enter course name in Notes master>

 Let’s talk about global permissions. Global permissions are system-wide and are solely
granted to Groups of users. They all control system-wide functionality as opposed to
project-specific features which are managed in permission schemes.

Regarding Jira System Administrators and Jira Administrators: People who have the
Jira System Administrators permission can perform all of the administration functions in
Jira. People who have only the Jira Administrators permission cannot perform functions
which could affect the application environment or network, for example, configuring Jira’s
SMTP mail server for notifications, configuring listeners, accessing logging and profiling
information, and so on. Either way, any user with any of these global permissions is
considered a Jira administrator throughout this course.

The Browse Users global permission is needed for selecting users or groups in most 'User
Picker' menus and popup screens throughout Jira, for example when sharing dashboards.
Whomever you grant Browse Users global permission to can see everyone else, which is
a security consideration if Jira is accessible externally. Note that the Assign Issues project
permission also allows a limited version of this on a per-project basis. You can assign
issues to anyone that has the Assignable Users permission regardless of this global
permission.

19 - Project Administration in Jira Server

 The Create Shared Objects global permission enables users to share a filter or
dashboard globally, or with groups of users. It is also used to control who can
create an Agile board, which is a shared object.

The Bulk Change global permission gives users the ability to modify a collection
of issues at once. For example, resolve multiple issues in one step. ( Bulk Edit,
Bulk Move and Bulk Delete are also further subject to project-level permissions).

The Manage Group Filter Subscriptions global permission lets users create and
delete group filter subscriptions.

19-<Enter course name in Notes master>

 Let's look at groups and project roles in Jira.

Project roles are similar to groups. The main difference is that group membership is
global, whereas project role membership is project-specific.

Additionally, group membership can only be altered by Jira administrators, whereas

project role membership can be altered by project administrators.
Using static groups in schemes mostly mean that schemes cannot be easily shared
between projects with unique project members. Any permission scheme-related
requirements must then be enforced by a Jjra administrator which increases the
maintenance overhead.

Project roles, on the other hand, are a flexible way to associate users and/or groups with
particular projects. A project role is kind of a bucket that holds individual users or groups. The
members of project roles are users/groups who fulfill particular functions in a project.
Project roles can be used in many places including permission and notification schemes, issue
security levels, workflow conditions and comment visibility. Project roles can also be given
access to issue filters and dashboards. But the core usage for project roles is for permission
and notification schemes. While you could assign permissions and notifications to users and to
groups directly, roles are more flexible and sustainable.

20 - Project Administration in Jira Server

Groups are used throughout Jira, as shown.

There are even some places where only groups can be used, and project roles cannot: for
example, application access and global permissions.
Upon closer examination this makes sense. Granting Jira access to members of a role
that exists only inside a Jira project would be an approach impossible to maintain.
Project roles, on the other hand, can be used in all relevant project schemes.
This makes sense since you always need a project context.
 Permission schemes also need to be seen within the context of one or multiple projects.

The number of permissions listed in a scheme may vary, depending on the applications
and apps you have installed.
In this example we see that both Jira Software and Jira Service Desk are installed, since
we have the Manage Sprints and Service Desk Agent permissions.
The theory, however, remains the same – project permissions control what users can or
cannot do on a project-by-project basis.

If you intend to streamline your administration and keep the overhead low, using project
roles in permission schemes is considered to be best practice. Why?
In the use case presented here, users (or) groups appointed to be project administrators
(meaning that they have the Administer Projects permission) can decide who will be able
to create issues in their projects, by associating individual users or groups to the project
roles that are granted the Create Issues permission.

In our scenario, the Consultants project role is granted the Browse Projects permission in
the Business Permission Scheme. Then that permissions scheme is used in multiple HR
projects – Human Resources, Onboarding, and Internal Training.

23 - Project Administration in Jira Server

 In each of those projects the project administrator has assigned different users or groups
to the role. So the two consulting users, Ravi and Sue, can browse projects in the Human
Resources project. The three consulting users, Sam, Ava, and Nalini, can browse projects
in the Onboarding project and the Internal Training Consultants group can browse
projects in the Internal Training project.

By using project roles, Jira administrators can use fewer permission schemes. Fewer schemes
means better performance. It also means Jira administrators can share schemes and save a lot
of administration work.

Using roles also reduces the workload on Jira Administrators because project
administrators are able to assign users and groups to project roles. That means Jira
administrators can focus on the tasks that can’t be delegated to project administrators.

While using project roles is considered best practice, whether you use project roles or
groups in a permission scheme sometimes depends on company guidelines. What you
should avoid, however, is granting permissions to single users in a permission scheme.
This approach is difficult to maintain and will likely not scale.

24 - Project Administration in Jira Server

Project permissions can be clustered into standalone permissions, interrelated
permissions, and standalone permissions that need to meet global prerequisites in order
to have an effect.

Let’s start with the standalone permissions.

Most permissions in each permission scheme control just a a single functionality, like
creating or deleting issues, and do not have any cross-impact on other projects or
permissions.

Let's take a look at 2 permissions that are more powerful and have wider effects.
First, the Browse Projects permission.

You need this permission as a pre-requisites for almost any other permission in a
permission scheme. It controls who has access to a project, and consequently who has
access to individual issues in that project.
If you can't browse projects, you can't see issues.
If you can’t see an issue you can’t edit, transition or comment on it.
Restricting the Browse Projects permission will even have an effect on what the users
will see on dashboards and in filters, and ultimately even what they receive as email
notifications.
This means that whether you're configuring permission schemes or troubleshooting
permission, visibility or notification issues, you always have to take a close look at this
particular permission.
Another standalone permission with underlying complexity is the Edit Issues permission.

As you might think, it controls who can edit or update an issue, and in particular, edit or
update the field values of an issue.

• It's important to remember that if you want to edit a field, it has to be present on the
screen associated with the relevant Edit Issue operation.
• Additionally, the field needs to be editable, and not hidden, in a field configuration

• Editing an issue type is a common point of confusion. Issue types can be edited or
updated directly, but the base rule is that the configuration of fields and screens must
be either identical, or shared, between the current issue type and the new issue type.

• Another common configuration that administrators run into is the combination of the
Edit Issues permission and workflow properties. Workflow step properties such as
jira.issue.editable will make issues read-only even for users that have the Edit Issues
permission. This configuration can also mean that issues cannot be updated in bulk
using the Bulk Edit issue operation.

As you can see, the Edit Issues permission often needs to be analyzed alongside screen
 schemes, field configuration schemes and even workflow schemes when
planning or troubleshooting a configuration.

This brings us to other permissions, those that are interrelated.

27-<Enter course name in Notes master>

Interrelated permissions are permissions that will not have any effect unless combined
with other permissions, or that will not function unless other prerequisites have been
met such as the user having active application access.
• Take the Move Issues and Link Issues permissions, for example: Users will not be able
to move an issue to another project if they don’t ALSO have the Create Issues
permission in the target project.
• The same goes for linking issues. If you do not have access to the issue to be linked
(through the Browse Projects permission and / or applicable issue security levels) you
cannot link to that issue.
• Scheduling issues means editing the due date, or ranking issues on Jira Software
boards.
• Technically users edit the fields 'due date' or 'rank'.
• The implications are that for both actions, users also need the Edit Issues permission
which we just talked about.
• The next permission, Assign Issues, is directly related to another permission, the
Assignable User permission. If the Assignable User permission is not granted to
anyone, users cannot assign issues because there is no one to assign them to.
• The last two examples, Service Desk Agent and View Development tools, are project
permissions that only apply if you have either a valid Jira Service Desk or Jira Software
license, and the users have the appropriate application access.
Strictly speaking, all of the interrelated permissions that we talked about have some
global or inter-project pre-requisites. Nevertheless there are some project permissions
that can be disabled globally. This is the reason they deserve special discussion here.

The Link Issues permission was already mentioned before, since it’s connected to other
permissions.
However, linking, time tracking, and watching and voting, are Jira features that can be
globally disabled.
If disabled, none of the related permissions will have any impact on projects.
Understanding permissions is crucial when working in Jira.

Understanding their context – whether global, project-related or issue type-related - is

equally important, as seen in our initial use case. Many configuration elements
throughout Jira will have an impact on permissions.

Before we start going through more use cases, let’s have a final look at a comprehensive
overview of most of the configuration elements that will be involved in our use cases…
This overview contains most of the configuration elements that might need to be
examined when handling permissions questions or troubleshooting scenarios.
We will not explain every element in detail at this point but you can clearly see that
permissions are connected to most areas of a Jira configuration. As we go through use
cases we will pinpoint all of these areas and explain why they need to be analyzed.
Having covered the basics, it’s now time to dive into the heart of this training: the use
cases.
Before we start with the common configuration use cases, we want to establish a
generic approach that we will use throughout the training. Ideally you can adapt this
approach to your organization and your daily work.
Approaching requirements or fixing problems can, to some extent, follow the same basic
process or approach.
- First of all, we need to fully understand the requirement or problem
- Once we have understood, we need to analyze our current situation or setup. This
includes all the configuration elements we just talked about in the previous module
- If there is a gap between the current setup and a target setup, we need to analyze it
and come up with potential strategies to bridge that gap
- In most cases there is no single “best” approach. There might be best practices or
industry standards that we will point to today but in the end YOU need to make a
judgement call -- not in this training, but back in your company, since every company is
different and has distinct policies and regulations, platforms, architecture, guidelines
and processes.
- Once you've identified your solution, you typically need to implement it by changing
some configuration, but sometimes all you need to do is inform your users how THEY
can act to bridge the gap individually.

Let’s have a look at how we could apply this approach to a simple use case.
One external consultant needs access to a billing project to be able to review issues and leave
comments.

Understanding the requirement is the first step in our approach

As in our first example today, we're looking at a seemingly simple use case. But do we
fully understand the requirement?
Until you understand a requirement you usually need to ask many questions.
Asking questions is better than assuming you understand all the details.

In our case we can ask:

•Who is the
consultant?
•What exactly does
 he need to do?
•Which project is
affected?

40-<Enter course name in Notes master>

Once you have the level of detail that you need in a requirement, you need to start asking
more questions to start your analysis with establishing the baseline, or the current setup.
These simple questions define three core elements that will always have to be analyzed
when dealing with permissions:

WHO, WHAT and WHERE

- Who addresses questions or information that are user-related (from roles,
groups, custom fields, to user directories and application access).
- What defines the scope of the the actual desired configuration changes,
desired actions or intended behavior. In this case they are mostly related to
permissions or Jira issue features.
- Last but not least: Where. The where provides the context of a requirement or
problem (is it global, project-, or issue-type related?).

Once we collect all information related to these 3 clusters we have established

the current setup and can start analyzing the gap to a target setup.
To get started, let’s have a look a common questions to ask in each cluster.
Let’s start by looking at the user who is involved in our scenario. To get a clear picture of
Milo there are a few questions that we could ask:

• Is our Jira instance public or private?

• Does Milo have valid application access?
• Does his user need to be created?
• Do we manage users in the internal directory or externally?
• What is his user name?
• Is he member of any groups or project roles?
Well, hello Milo Anderson, a regular Jira user, member of multiple groups and project
roles already working in various projects.
Speaking of projects…
Apart from permissions with global prerequisites, any permission-related configuration
or troubleshooting use case needs to be analyzed within the scope of a project!
Only when associated with a project through a permission scheme will a permission
mapping actually have any effect!
During this phase of the analysis the bulk of the information has to be gathered. The
number of questions to ask and potential answers to be found greatly depends on the
complexity of the requirement.
There is no specific order in which to ask these questions but in the end each of the
answers will mark a decision point that will ultimately need to be considered in the next
steps of our generalized approach – the gap analysis and the implementation of a
solution.
Take half a minute to look over our preliminary questions.

(Narration pauses for 30 seconds.)

In this case, after research we established to following:
• Milo does not have access to the BILL project.
• The permission scheme is not shared.
• There is a project role called Consultants that was granted all the relevant
permissions, and only those.
• Milo will only need temporary access.
• The project administrator should implement the change.
Recall the graphic we showed for a previous use case.
It shows the current setup we wanted to analyze.
It contains all major configuration elements we've identified.
Now it’s time to analyze the gap!
Analyzing the gap basically means identifying all configuration elements that might
need to be updated in order to meet the requirements.
In our current use case the gap is quite obvious: Milo needs access and certain project
permissions in the BILL project – namely:
- Browse Projects,
- Comment on Issues,
- and the 'Transition Issues' project permissions

These permissions can be granted to him by updating the project's permission scheme,
which you'll recall was not shared. This means that a potential update will not affect any
other project – this is really important. If it was shared, we might have needed to look for
a different solution.

The permissions could be granted to Milo personally, to a group he is a member of, or to

a project role. Now it’s time to identify the best implementation.
As soon as you have more than one potential solution to meet a requirement or to fix a
problem, it might be up to you to decide, or the decision might need to be made to align
with company guidelines.

Especially when you're deciding on a good implementation for a new configuration, there
will most likely be multiple possible approaches.

The simplest approach is to often "do whatever your users request and don’t ask any
questions!"

5 new issue types: OK!

20 new custom fields: OK!
10 new projects: OK!
4 additional resolution values: OK!
2 new Jira instances: OK!

When managing Jira, this approach is probably the worst you could choose, and should
be avoided at all costs.

Instead of cluttering your instance, you should consider all the factors that need to be
 evaluated (from your instance size, to your process guidelines, to the time it will
take to find a compromise that all 10 development teams can live with) and
make a careful judgement.

Ideally, an implementation should be:

• Robust: This means, for example, it should not include individual users in
dedicated schemes. Users come and go or even go on vacation. Don’t let your
configuration depend on single users.
• It should be future-proof: You don’t want to have to update your
implementation every time a new consultant comes on board
• It should be scalable: Project roles scale easily, while using groups in
schemes will mean more maintenance. Most importantly, using project roles
helps prevent unwanted side-effects on other projects.
• It should be transparent: For example, find one implementation and share it –
for example between all development projects. Developers often work in
cross-functional teams and projects. If all projects are configured similarly
this will result in less irritation.
• Finally it should be manageable: Try to be generic! For example maybe
adding a new role to grant read-only access is better than maintaining 50
individual permission schemes…

Let’s have a look at our use case.

50-<Enter course name in Notes master>

Each permission can be granted in multiple ways. In our case we are looking at granting
Milo three project permissions:
- the Transition Issues permissions
- Comment on Issues
- and the Browse Projects permission

When analyzing our current setup we identified a current project role called
Consultants that exists in the BILL project and that has all and only the relevant
permissions.
Again, if the role had more permissions than Milo actually needs, we would
probably look at at different solution.
Since the permission scheme is not shared, and so we don't have to expect any
side effects, our best approach would be to simply add Milo to the existing
project role.
In fact one of the initial requirements was that the project administrator should
be able to implement the solution. Since project administrators can update role
memberships we not only found the best, but also the only valid solution.
Let’s complicate our use case:
Instead of one consultant, let’s assume that 10 consultants need access two two projects. The tasks
they need to perform are identical to the first use case.
As a bonus, they also need to create dashboards and share them with the internal billing team.
As a start we need to understand the full picture.
So after asking the first questions we establish that:
Ten external consultants, all existing Jira Core users, need access to two billing
projects, BILL and BILL_EXT, to be able to transition issues and add comments.
They also want to create dashboards and share them with the internal billing team,
which has access to both projects.
As soon as we dive into the analysis of the current setup we gather facts that are already
known from our previous use case:
The first of our two projects, BILL, has a not shared permission scheme, and a
Consultants project role exists which has all required permissions.

We now collect information on the new users and the yet unknown project.
- The good news is that all consultants have existing Jira users and valid Jira Core
application access.
- Since BILL_EXT is a business project, that was an important fact. If it had been a
Service Desk project we might have to take make some more decisions at this point.
- We can also re-use the existing Consultants project role, since it has been granted the
same permissions as in our other permission scheme.
- The new consultants also need to create and share dashboards, so we have to look at
global permissions: Currently the global permission “Create Shared Objects” is only
granted to the group “staff-internal”, and no dedicated group exists for external
consultants at this point.
To bridge the gap we need to make sure that all users get the project permissions they
need in both projects. This can be done by adding the users to the Consultants project
role
Additionally we need to grant them the global permission to Create Shared Objects. This
permission can only be granted to groups.
What are our actions?

Project permissions can be granted in various ways: to groups, project roles, individuals,
or meta users such as assignee or reporter.
We decided to add the users to the existing project role for all the reasons mentioned
previously. Now we have two options:
Adding users individually or adding a group.
In our use case the second requirement, being able to create and share dashboards, gives
away the best approach. We need to create a group for the external consultants anyway
since the relevant global permission, "Create Share Objects" can only be granted to
groups.
Why not simply add the new users to the internal staff group? This might enable them to
create shared dashboards but – apart from not being internal employees – this might
give away too much access, grant too many permissions or even cost licenses, depending
on the Jira setup.
Since we are looking for the best implementation:
- let a Jira administrator create a dedicated group
- add the users
- add the group to the relevant global permission
- and have project administrators add the group to each project role.
Trick question: What if the dashboards should ONLY be shared with the internal billing
team and no one else?
You can share a dashboard either with all users that have access to the project, with
dedicated project roles, or with groups that you are a member of.

If the internal billing team should not be mapped to a project role for the consultants to
share dashboards to, we might have to create a new group with internal billing team
members AND external consultants.
Only then could the new consultants share the dashboards solely among themselves
and the internal billing team.
Our next use case is rather generic: Only specific users should be able to close issues.
What does that mean?
Who are the specific users and what does closing issues mean?
In our case it means Only members of a dedicated management team should be able to
execute the various transitions leading into the Closed status of each issue workflow.

The requirement applies to all five development projects in Jira.

So let’s have a look at all relevant projects and the users that are part of the dedicated
management team.
Let's look at users and projects.

We quickly figure out that all relevant users exist in Jira and have Jira Software
application access. The user directory is external, but local groups have been enabled.
They were also granted access to each project by a shared permission scheme
individually.
Additionally, each project has a unique workflow scheme, with slightly different
workflow configurations, which is worth investigating further.
Now let's look at project permissions and workflows.

Analyzing the current setup, we identify that members of the management team have
access to the projects, but they currently do not have the Transition Issues permission.
Permission to transition issues is a pre-requisite for them to be able to close issues.
The individual users have access to the project through their membership of a project
role that is associated to the project.
Closing issues - or to be more specific, the execution of each transition into the Closed
status - is currently unprotected. By this we mean that that no validators or conditions
restrict execution of these transitions. That also needs to be taken care of.
Now, what are our actions?

In our case, the management team is a rather static group, and membership is identical
across the organization, and thus across all projects.

Using a project role would be an option, as it was in our previous use cases, but
managing a group and using that group to update the shared permission scheme and
the various workflows seems to be the better option. Why? A group can be managed
centrally and potential updates to the members would only have to be carried out once
instead of updating the role memberships in all five projects.

This leaves us with the following approach:

1. Create a dedicated group for all management team members
2. Grant the newly created group all relevant permissions in the shared scheme –
especially the Transition Issues permission
3. Apply a workflow condition to each relevant transition in each workflow to limit
execution to the dedicated group

The only question remaining is: Should we use a Permission condition or a User Is In
Group condition in the transitions?
The answer is: It depends!

Some common questions at this point would be:

• Do you actively use the permission in another context? If yes, you would have
unwanted side-effects such as granting users more power than they actually need.
• Do you want to maintain the configuration in your workflows or in your permission
scheme? This question is important if any of the configurations are being shared.

• One goal should always be to keep your configuration clean and generic. This is why we suggest using a
permission condition in each transition, and controlling access by modifying the shared permission scheme.

Why? Let’s suppose that in the future, other teams, users or roles need to execute this transition. All you would
have to do is add them to the relevant permission, as opposed to updating each independent workflow. Jira
even ships with a built-in Close Issues and Resolve Issues permission which is often used for this exact purpose.
In use case #4, requirements have changed.
It's similar to the initial use case: Only specific users should be able to close issues.
This time, however, we update the parameters of the requirement: project administrators need to
individually decide who can close issues for their projects.
Upon closer look, we learn that these users are dedicated QA engineers, and they differ
on a project-by-project basis.

In this use case we'll only look at the bug issue type, but we'll look at workflows for 20
projects in total.
Let's look at users and projects.

We quickly figure out that all relevant users exist in Jira and have Jira Software
application access. This setup is identical to the previous use case.

It's not identical for permissions and workflows, though. Whereas the workflow situation
is rather simple, with only a single bug workflow that's used in all projects, each project
has a unique permission scheme.
Let's look more closely, now at the project permissions and workflows.

QA engineers exist as users in Jira, but some of them don’t even have access to the
projects they should be engaged in as quality assurance.

Granting relevant access and project permissions will therefore be one of the tasks to
close the gap.
Regarding the execution of the transitions into the Closed status – we find that this is
already protected via a workflow condition which is unrelated to the current
requirement.
What are our actions?

Since QA engineers vary by project, and membership needs to be controlled by project

administrators, there is only one real solution to implement this: a project role.
This role can be used in any of the permission schemes, and a dedicated 'User Is In
Project Role' workflow condition can be applied to all transitions to the Closed status.

Once set up, the only missing piece is to inform each project administrator about the
configuration changes. They are then able to individually add users to the newly created
project role to meet all requirements.

But…is there one more thing?

The answer is Yes!

The initial analysis showed that there was already a workflow condition in place on transitions leading to
Closed status, which should be left untouched. This is why we have to use the OR operator when
adding the new condition.
A common mistake is to simply add a new condition and group the conditions with an AND operator. In this
case BOTH conditions must be met and this is not what we want to achieve here (and in most other use cases).
Let's take a look at case #5:
We find that requirements have changed yet again!

As before, only specific users should be able to close issues.

This time, individual users ,on an issue by issue basis, need to decide who can close each issue.

By now you should be familiar with all the different decision points where you have to choose one
way or another.
Let’s assume that all users exist, and have all the relevant permissions.
We have also broadly covered that we need to secure relevant transitions with conditions.

This leaves us with the question: How can we implement such a specific requirement?
Instead of spending a lot of time on the analysis of the current setup and the gap, let's first
understand the requirement, and provide some ideas of potential implementations.
Understanding the requirement is crucial for this use case so we should start asking
some of the following questions:
• Who decides who should be able to transition the issues?

•Anyone, or just the

current assignee, or
members of a project
 role?
• When do they decide it?

•At some point in

the workflow, or at
any time?
• And finally: How do they decide?

•There are multiple

ways of “choosing”

72-<Enter course name in Notes master>

 or selecting
individual users to
perform certain
tasks – from simply
assigning issues to
users to setting
custom field values
72-<Enter course name in Notes master>
 - but each solution
comes with pros
and cons.
The number potential combinations of setup and target implementation is too
big too cover in this training.
What we will do instead is to provide some food for thought.

72-<Enter course name in Notes master>

In this complex use case, most of the configuration elements of Jira might be involved.
Why?

Let’s suppose you aim for a lean solution with built-in fields and workflow elements, and
you structure your implementation around the assignee.

• You make sure that only members of an certain project role can assign issues to only
certain users: a standard approach.
• You now secure individual workflow transitions with the Only Assignee condition, also
a standard approach.

But which configuration elements could potentially be involved in such a straightforward

solution? Almost all of them!
The permission to assign or be assigned issues can be granted to various “options” – from
individual users to project roles and groups.

How and where do you assign the issues? The assignee field might have to be put on a
workflow transition screen, or assigning issues must be prevented in other workflow
statuses.

And which issue types are we talking about?

Further, is this requirement related to a specific application? Non-agents cannot be
assigned any issues in a Service Desk project.

Also, do you use any apps? 3rd party apps are likely being used and need to be considered
as well.
Without going into much detail here -- think about using a combination of a permission
and a permission condition as an alternative!

Permissions can be granted to individual users who can be picked in a user-picker custom field. This would
bring Global Permissions back into the equation. An entire group can even be selected in a group picker field.

As always, there are many ways to accomplish a goal in Jira.

Let's move on, and focus on the requirement and target setups of the next use cases.
This is a very common use case: Users should have access only to issues they have reported.

Let’s ignore Jira Service Desk for now, since this use case is the foundation of the customer model.

Generally there are two ways to approach this.

One common approach is to use a standard issue security level and include only the
reporter of the issue.
The alternative would be to grant the Browse Projects permission only to the reporter.

In either case, the reporters would see only the issues they have reported.

What is the best solution? You'd need to determine that -- it would depend on other
factors and a proper analysis.

Let's look at the next case.

Only developers should be able to log time on bugs.
In the end the solution comes down to a permission: The Work On Issues permission.

If you have only the bug issue type in the Jira project that requirement relates to, this is
an easy fix.
Just grant the Work On Issues permission to only the project role or group that includes
all developers.
You can also individually limit the Work On Issues permission using workflow step
properties.

This might be tedious, but applying a property to each workflow step associated with the
bug issue type will get you the same result: Only developers can log time.
A 3rd alternative, which also relates to the permission mentioned, is to create a new
project with a dedicated permission scheme. This, on the other hand, brings us back to
the first solution, to limit the permission to only selected users.

Let’s have a look at the next use case…

You might have been confronted with this requirement: Only developers should be able to
create bugs.
The way to approach this is not what you might hope. If you have several issue types in a
scheme, you cannot limit the issue types that can be created to only a subset of users.
This basically means:

You either have to create a dedicated project with only the Bug issue type available, and
restrict the permission to create issues to developers only, OR…
You'll have to use a 3rd party workflow app, and limit the creation of the bug issue type
to dedicated users using a validator.
Before we start covering the second big topic of this training -- troubleshooting
permissions – let’s spend a minute recapping the major points we've identified so far.

Since you'll most likely have to choose one out of many approaches to meet certain
requirements, it's common practice to start with the most obvious configurations first –
let’s say granting a permission to an existing project role, before diving into the depth of
the Jira configuration and configuring workflow step properties.

Either way, try to implement a solution that matches the criteria established earlier on in
this training. To the extent possible, make your solution:
• robust
• future-proof
• scalable
• transparent
• and manageable
Troubleshooting permission-related problems can be a complex process. This next
chapter will focus on providing a general approach for you to follow, that will then be
tested against various use cases.
You most likely remember our first use case, where Alana needs to assign issues to Scott
when she is done reviewing his code.

We can easily turn that use case around and face a very common problem!
Basically the approach of troubleshooting a problem is mostly a task of reverse
engineering with two potential outcomes:

1. Outcome 1: The situation is NOT related to a configuration problem. It might be

caused by the end user OR it exists by design (especially when it boils down to
security or governance issues.)
2. Outcome 2: It is a configuration problem OR a requirement for a changed
configuration.

Whatever the outcome is, you will have to act and the following approach will help you
on the way.
- First of all, we need to fully understand the problem somebody is facing
- Once we've understood, we need to analyze our current situation or setup to identify
potential sources of the problem. This includes all the related configuration elements.
- If there is a gap between the current setup and a target setup, and the problem does
not exist by design, and it does not sit with the end user, then we need to analyze it
and come up with potential strategies to bridge that gap.
- Even if multiple solutions can solve a potential problem, finding the right one will be
much easier when troubleshooting than when coming up with an initial configuration.
Why? Because a lot of times it's fair to assume that the current setup has been
implemented using best practices and you just need to find the one missing
permission or the single configuration element that's problematic, instead of planning
out an entire configuration rollout.
- Either way, if there is a problem with the configuration, once you've identified your
solution, you will have to act and implement it.
- But remember, sometimes all you need to do is inform your users how THEY can bridge
the gap individually.
The emphasis of this approach will be on the first two steps:
Asking the right questions while establishing a baseline, and understanding the problem,
often leads directly to the only valid action that will solve it.
If the problem is not straightforward, it is crucial to analyze the current setup and get the
big picture.
Let’s start by understanding the problem by asking questions. Some factors can usually
be ignored, such as:
- Does Alana have a valid user license?
- Does she have access to the project?
- Does she have the transition issues project permission?

Obviously she has access and can transition issues, the problem is that she cannot
assign issues to a specific user during the Code Review Complete transition. This is what
you have to focus on to identify the real problem.

Ask questions like:

•Did it ever work?
 •Has something
changed?
•Is she new to the
project?
•Can she assign
issues in other
projects?
•Can others

93-<Enter course name in Notes master>

 assign issues?
•Can YOU assign
issues to Scott
during that
transition?
The answer to any of these questions might lead you to the source of the
problem.

93-<Enter course name in Notes master>

Start with the most obvious question: Is this by design? As a Jira administrator you have
either implemented the current setup or you know the right people who can answer that
question.
It it was by design, you have to either inform Alana, or request a design change from
relevant stakeholders.
If it is not by design, there is a misconfiguration or a missing configuration.
The route you take from here depends on the questions you ask.
There is no specific order in which to ask them: As a general rule of thumb keep thinking
about the most obvious sources and rule those out immediately.

Can Alana assign issues in any other projects? If yes, then the problem has to be
analyzed in a project context.
Can she assign issues of that same issue type using the standard Assign Issue action, as
opposed to setting the field in a transition screen?
If yes, then you know she has the relevant permissions needed to Browse the project and
Assign issues.
Let’s focus on Scott for a second: Can she assign issues to Scott using the Assign Issue
action?
If yes, this means that Scott has the needed Assignable Users permission.
It seems that the problem is related to the workflow configuration. This is what you have
to focus on now.
Can others assign issues during that transition? If the answer is yes, the problem is not
connected to the configuration of the transition screen.

What is the missing link? Is it the transition itself? Or does it have to do with In Code
Review status?

Can Alana use the transition? If the answer is yes, we can rule out the Transition Issues
permission, which leaves us with a very specific configuration.
While Alana has the Assign Issues permission, a workflow step property can further limit
the Assign Issues permission to a certain group, role or to individual users, when the
issue is in the In Code Review status.
Fixing a problem can range from simply adding a user to a role, to creating entirely new
projects.

Either way, all factors and best practices that you should try to apply when you're
designing solutions for new requirements-based configurations also apply to fixing a
problem.

The solution in this use case could be adding Alana to a group that is used in the
workflow property, or adding a group that Alana is in to the workflow property. You
could update the workflow property to use a role instead of a group, or you could
simplify the workflow by removing the property altogether.
You might not be able to make the decision yourself, since it may have other
implications, especially when adding a user to groups or roles. As a general rule of
thumb, try to implement a robust and future-proof solution instead of going for the
quickest fix.

Quick fixes might save you time now, but will most likely result in more work and an
overly complex and messy configuration in the future!
Here's a another simple problem to troubleshoot.
Tom cannot view the workflow diagram of issues in the DEV project.
Understanding this problem is straightforward: Tom cannot see the View Workflow link
in any issue of the DEV project. Others can see the link to view the workflow diagram.
Identifying the single source is easy, as long as you are familiar with the fact that there is
a dedicated standalone permission that controls who can view the Read-Only Workflow
diagram for any given workflow per project.
Tom obviously does not have this permission.
Whenever you are quite certain that a behavior is related to a missing permission, Jira
offers a tool which can help you quickly prove your assumption: The Permission Helper.
The Permission Helper is part of the Jira Admin helper, also includes a field helper and a
notification helper.
You simply have to provide a user name and the permission you want to analyze, and the
permission helper tells you whether a user has or has not been granted that permission
and – very helpfully– how the permission has been granted.
For example the Permission helper will tell you that the View Read-Only Workflow
permission has been granted to the Developers group and the Dev project role and that
Tom is not a member of either.
Tom needs to be granted the View Read-Only Workflow permission. Do you add Tom to a
group, or to a project role, or do you create a new project role?
How you grant that permission is up to you, but you have to be aware of the implications
– especially if the permission scheme is shared, or if adding Tom to a relevant group or
project role has an unintended result - for example the change gives Tom access to
previously secured issues, or even additional application access.
In our next use case, Sarah cannot add the due date to an issue.
She wants to add the due date directly when creating tasks in the Marketing project.
Apparently other project managers can set the due directly upon creating the issues.
If you have listened closely when we talked about permissions at the beginning of this
training, the solution should be obvious!
It’s a fact that the due date has to be present on the screen that is associated with the
Create issue operation for the Task issue type.
So this leaves us with the Edit and the Schedule Issues permission. Sarah can edit the
issue but not set the due date, so she is lacking the Schedule Issues permission.
As in the previous case, Sarah simply needs to be granted the Schedule Issues permission
in an appropriate way.
Of course you'll need to think about the implications. The permission itself is harmless,
but as we've discussed, making changes to group or role memberships can have side
effects that you must be careful to anticipate.

Let’s speed up the process and look at some more advanced use cases…
The next troubleshooting use cases all relate to issue access.
This case case closely relates to a configuration use case we covered earlier: Users should have
access only to issues they have created.
The outcome of a misconfiguration might result in a situation where a user creates an issue in a
project but cannot access it afterwards. An alternative would be that a user moves an issue to
another project but cannot access it afterwards.
The source of the problem will be either permission-related or related to issue security.

• Start by checking the Browse Projects permission in the affected project and grant the
user the Browse Projects permission. In most cases this will fix your problem. If not…
• …make sure that the user is included in the default security level that is applied to
newly created issues.
• Alternatively, 3rd party apps allow you to set security levels as post-functions. The
solution is identical though: Make sure the affected user is included in the security
level that is being applied.

Let’s stick to the topic of moving issues, since it is a rather complex one.
Moving an issue might seem straightforward, but there are a few things to keep in mind.
Let’s start with the most obvious one: A user complains that he cannot move issues in a specific
project. The source of the problem and the solution is obvious: He does not have the Move Issues
project permission and you have to grant it by updating the permission scheme.

The second problem, which is another common one, is related to a lacking permission in the target
project. A user can move issues but cannot select a specific target project.
If you want to move an issue to another project you need the Create Issue permission in the target
project!

A common misconception is that you also need the Browse Projects permission, which is the
foundation for accessing a project. You don’t need it, strictly speaking.
However, it is highly recommended to also grant the user the Browse Projects permission as well.
Why? Otherwise you run into the problem presented in the previous case. A user moves an issue
but cannot access it afterward.
To easily check whether users have all the needed permissions, the Permission Helper can be of
great help.
Let’s move on to problems with mentioning users.
@ mentions (at-mentions), or smart mentions, are a great way of keeping users in the loop. What
could possibly go wrong?
Let's take a look.

• If smart mentions do not work at all for a user, he is most likely lacking the Browse Users global
permission. You need this permission in order to “look up” other users.

• The second use case is a little more complex. What if smart mentions work in general, but the
autocomplete feature does not suggest a specific user? As the name of the feature
suggests, we are looking at “smart” mentions.

If a specific user cannot be mentioned, it is because the user does not have access to that
specific issue – either because he generally cannot access the project at all or because
the issue is secured via a security level the user is not a member of.
This is most likely not a general problem -- the behavior is most likely by design. You
need to question whether the other user needs access or not.
Let’s continue by looking at potential problems that can occur around logging time.
• The first problem is that nobody can log time on any issue at all. This comes with an easy fix: If
nobody can log time in Jira, most likely the global Time Tracking feature is disabled. You just have
to check whether this is by design or by company policy.
• The second problem is that Users cannot log time in a specific project or a specific issue
type.
• This problem can have multiple sources. Users cannot log time in a specific project or a
specific issue type.
• Start by looking at the Log work issue action.
• If users were lacking the Work on Issues permission, or if the Time Tracking field was explicitly
hidden in the field configuration for any given issue type, the Log Work action would not be
available.
• The same holds true if this behavior is showing only for issues in particular statuses.
Remember that you can further limit project permissions by using workflow step properties!
• Last but not least: If users can generally log time using the issue action, the problem will be
related to a screen configuration. If you want to enable users to log time when they are editing
an issue, for example, you have to add the Time Tracking field to all relevant screens.
• Remember though: There might be business reasons why logging time is unwanted in certain
situations.
Before we wrap up, one more time let's compare approaches for configuring or
troubleshooting permission-related requirements or use cases.
Fully understanding a requirement or a problem situation is the key to success.
Once you have gathered enough information to understand the situation you will have to
analyze the current setup, and identify the potential gap between the current a target
setup.
When troubleshooting problems, this process might be simpler than when dealing with
general configuration requirements, since we can assume that the target setup is
already in place and you simply have to spot the source of your problem. You even have
built-in tools to support you on the way.
The crucial part in either approach is coming up with a solution. The principles or best
practices of applying a good solution have been covered extensively throughout this
training.
Remember, try to avoid a quick fixes, and aim for robust solutions, whenever possible!
That’s it for this training on Configuring and Troubleshooting permissions in Jira. Atlassian
University offers various free trainings like this one – so if there is any other topic that you
want to explore further, head over to atlassian.com/university and continue on your
learning path.
We hope you enjoyed this Skillbuilder training and learned useful things that will help
you in your daily job as Jira administrator.

Fur further information, visit our online resources including Atlassian University,
Atlassian Community and Atlassian's product documentation.

For more in-depth help, contact Atlassian Support or locate one of the Atlassian
Solution Partners near you.
Congratulations on completing this Configuring and Troubleshooting Permissions in Jira Skillbuilder
course!