JIRA-Admin-Pt1-Lab Workbook

JIRA Administration Part 1:
Getting up and running
Lab Workbook
Copyright © 2016 Atlassian Pty Ltd. All rights reserved.
Atlassian TM, Atlassian Bamboo TM, Atlassian Clover TM, Atlassian Confluence TM, Atlassian
Crowd TM, Atlassian Crucible TM, Atlassian Marketplace TM, Bitbucket TM, Confluence TM,
Confluence Questions TM, FishEye TM, HipChat TM, JIRA TM, JIRA Portfolio TM, JIRA Service
Desk TM, SourceTree TM, TM , and TM are trademarks of Atlassian Pty Ltd. All other
trademarks and trade names are the property of their respective owners. Information in this
document is subject to change without notice. Websites, names, and data used as examples in
this document are fictitious unless otherwise noted. No part of this document may be
reproduced or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording by any information or retrieval system, for any purpose, without
prior written permission of Atlassian Pty Ltd. Address inquiries to Atlassian Pty Ltd, Level 6, 341
George Street, Sydney, NSW 2000 Australia
Table of Contents
Introduction...................................................................................................................... 1
Lab 2 – Configuring Your System ................................................................................... 2
Scenario .................................................................................................................. 2
Exercise 1 – Verifying Applications & Configuring Integrations .............................. 2
Exercise 2 – Configuring the User Interface .......................................................... 18
Exercise 3 – Log Files, Auditing & Support Tools ................................................. 23
Optional Exercise 4 – Exploring Configuration Settings ....................................... 29
Lab 2 Appendix ..................................................................................................... 34
Lab 3 – Setting Up Users & Groups .............................................................................. 35
Scenario ................................................................................................................ 35
Exercise 1 – Exploring User Directories ................................................................ 35
Exercise 2 – Exploring Users and Groups............................................................. 39
Exercise 3 – Creating a New User ......................................................................... 54
Optional Exercise 4 – Deactivating a User & Exploring Access ............................ 57
Lab 3 Appendix ..................................................................................................... 64
Lab 4 – Configuring Global Permissions ...................................................................... 65
Scenario ................................................................................................................ 65
Exercise 1 – Configuring Administrator Permissions ............................................ 65
Exercise 2 – Removing the Bulk Change Permission ........................................... 78
Optional Exercise 3 – Exploring Non-Administrator Permissions ......................... 80
Optional Exercise 4 –Exploring the JIRA Administrator Differences ..................... 85
Lab 4 Appendix ..................................................................................................... 89
Lab 5 – Creating & Configuring Projects ...................................................................... 90
Scenario ................................................................................................................ 90
Exercise 1 – Creating a Project ............................................................................. 90
Exercise 2 – Updating the Workflow for a Project ................................................ 98
Exercise 3 – Updating Fields & Screens in a Project .......................................... 116
Exercise 4 – Adding an Issue Type to a Project & Changing its Workflow ......... 123
Optional Exercise 5 – Updating a Workflow & Viewing Your Activity ................. 131
Lab 5 Appendix ................................................................................................... 133
Lab 6 – Configuring Project Roles & Permissions ..................................................... 135
Scenario .............................................................................................................. 135
Exercise 1 – Assigning Project Roles .................................................................. 135
Exercise 2 – Creating Project Roles & Configuring Project Permissions ............ 143
Optional Exercise 3 – Viewing Other Role & Permission Information ................. 155
Lab 6 Appendix ................................................................................................... 157
Lab 7 – Sharing & Customizing Project Configuration .............................................. 159
Scenario .............................................................................................................. 159
Exercise 1 – Creating a Project with Shared Configuration ................................ 160
Exercise 2 – Editing a Shared Project Scheme ................................................... 165
Optional Exercise 3 – Backing Up & Editing the Default Notification Scheme ... 172
Optional Exercise 4 – Deleting a Project & Sharing a Scheme ........................... 176
Lab 7 Appendix ................................................................................................... 181
Introduction
Let's take a minute to review how this Lab Workbook is organized. You’ll find
instructions for each lab in this course. Each lab has the following sections:
• Scenario: Describes what you will do in the lab. This section lays out the use
case and other details you need to know.
• High-level Instructions: Challenging, less detailed instructions if you like
figuring things out on your own.
• Detailed Instructions: If you prefer to follow step-by-step instructions, use the
more detailed instructions.
There are also appendices, which you don’t need during class. They are full of useful
information like additional technical detail, best practices and additional reading – all
conveniently grouped by lab. Dig into this section after class!
Lab access and login instructions follow:

• Access to JIRA is explained in a handout called "Accessing Atlassian in
CloudShare" PDF document – please find this document in your on-line
registration and follow the instructions.
• Log in to JIRA using the credentials for the users specified in each lab. Two
examples are shown in the table below.
User Details
Alana Grant Username – agrant
Password - Charlie!
Mitch Davis Username – mdavis

Password - Charlie!
JIRA Administration Part 1 – Lab Workbook 1

Lab 2 – Configuring Your System
Scenario
Teams In Space is a fictional company that specializes in space travel for teams.
They are distributed across the universe. They have just installed JIRA to allow their
distributed teams to run more efficiently, so that tasks are visible, shared and easy to
access.
You are the JIRA administrator. The JIRA applications (Software, Service Desk, and
Core) have just been installed. Now you need to set up and configure the instance so
your teams can start using it. You have one day so let's get started!
As the default JIRA administrator, admin, you perform the following tasks:
• Verify the installed and licensed applications
• Integrate Confluence with JIRA
• Install an add-on
• Configure the look and feel of your JIRA instance
• Customize the default dashboard
• Locate the JIRA log
• Configure auditing
• Use Support Tools
• Optional - Explore other configuration settings
Exercise 1 – Verifying Applications & Configuring Integrations

High-level instructions
If you would prefer to follow step-by-step instructions, go to Detailed Instructions on
Page 6.
1. Download your lab resource files and log in to JIRA:
a. Getting access to JIRA for this class and accessing any lab resources
files is explained in the PDF file Accessing Atlassian in CloudShare.
You should have received this document as part of your class
registration process.
b. Log in to JIRA as the Administrator (admin/Charlie!).
c. You see the default System Dashboard.
2. Access the JIRA Administration pages:

a. Navigate to the JIRA Applications > Versions & licenses administration
page using one of these methods:
i. Click the gear icon on the right side of the JIRA banner. Select
Applications.
ii. Or, type . (period) or gg then type versions and click Versions &
licenses.
If the dialog says 'No Matches' you may either have entered the name
incorrectly or your VM session has timed out. Click the reload icon in the
browser to resume your VM.
2 JIRA Administration Part 1 – Lab Workbook

You may be wondering why you were asked for your password again.
This is because JIRA protects access to its administrative functions by
requiring a secure administration session. When a JIRA administrator
(who is logged into JIRA) attempts to access an administrative function,
they are prompted to log in again.
b. You may see a message recommending you perform a re-index. This

message appears when major configuration changes are made which
can cause the search index to become out of sync with JIRA's
configuration. This can affect searching for issues. There are no issues
created yet on your instance but it's a good idea to perform the re-index
when you see the message. You see it now because of the way the
classroom virtual machines are created.
i. Click perform a re-index.
ii. On the Indexing administration page in the Re-Indexing
section, click Re-Index.
iii. Once the re-indexing is complete click Acknowledge.
iv. Return to the Versions & licenses administration page.
3. Verify the installed and licensed JIRA applications as well as the user count by
viewing the Versions & licenses page.
You may see out of date or incompatibility warnings something like the
screenshot below. This is because JIRA checks versions dynamically and
alerts you if new versions are available. Also the version numbers may be
slightly different from what's shown above.
Do not upgrade or install new versions! The versions that this

course VM was created with will work for these labs.
What applications are installed and licensed?
Answer: JIRA Service Desk, JIRA Software, and JIRA Core are installed
and licensed.
How many users are licensed and how many already used for JIRA
Software?
Answer: 100 users are licensed and 1 user license is already used (by
the JIRA administrator user, admin).
When does your maintenance expire for JIRA Service Desk?
Answer: View the date next to Maintenance expires.

4. Integrate Confluence with JIRA:
a. One of the most common integrations is JIRA and Confluence. They are
typically installed together and Teams In Space has done so. Navigate to
the Application links administration page.
b. To get the Confluence URL, copy the DNS name from your address field
in your browser i.e. everything before the port number. For example,
uvo1w6mm7awmkst8v0.env.cloudshare.com.
c. Paste this into the Application field then add the remaining part of the
URL including the Confluence port number and application name in the
following format:
http://<DNS _name>:8010/confluence
d. Create a new link.
e. On the Link applications dialog, leave the defaults and continue.
f. You are now redirected to Confluence to create the reciprocal link. Log in
as the Administrator, admin/Charlie!.
g. In the Link applications dialog in Confluence, click Continue.
h. You are now redirected back to JIRA and it completes the configuration
of the link. You should see a message that the link was created
successfully. (You may need to wait a minute for this to appear.) If not,
edit the link and double check the spelling and format of the URL.
i. There's one more step you need to do because of the way we have the
VMs set up in our training environment with the same base URLs. In our
setup the only difference between the JIRA and Confluence base URL is
the port number.
For production installations, set up JIRA and Confluence on separate

servers.
j. Edit the Confluence application link:

i. For Outgoing Authentication, select the OAuth tab then check
Enable outgoing 2-Legged OAuth with Impersonation. Update
and ignore the message that appears.
ii. On Incoming Authentication, if a dialog pops up, confirm you
want to leave the page. Select the OAuth tab, check Allow user
impersonation through 2-Legged OAuth. Update then close the
dialog.
5. Verify Confluence integration:
Do you notice anything different about the JIRA header at the top of the
page?
Answer: Now you see the application navigator icon (three horizontal
bars) on the left side of the JIRA header.

a. Use the application navigator to go to Confluence then again to return
JIRA.
Now your users can easily move between JIRA and Confluence, create
Confluence pages from within JIRA, and create JIRA issues from
Confluence.
b. Navigate to the Application Navigator administration page.
Here you see an entry for Confluence. When you create an application
link, JIRA automatically adds it to the Application Navigator. Here you
can add links to any other applications your users need quick access to
by providing a name and the URL. You can also restrict access to certain
groups of users. And you can specify the order of the links.
6. Install an Add-on:
a. Navigate to the Manage add-ons administration page.
b. View the add-ons that are pre-installed. Here you can install, update,
enable, and disable add-ons.
c. You can view add-ons in different ways. By default it shows user-
installed add-ons. Display all add-ons.
d. Find just the Hipchat add-ons.
e. Navigate to the Find new add-ons page and find the most popular add-
ons that are free.
Here you can find and discover add-ons via the Atlassian Marketplace.
All the ones you see are compatible with your JIRA version.
f. The JIRA Calendar Plugin looks like it would make it easier for your users
to enter dates. Install the JIRA Calendar Plugin add-on.
g. On the Manage add-ons page, find the JIRA Calendar add-on and view
details about the add-on.
7. To start the next exercise, go to page 18.

Detailed instructions
These are a repeat of the high level instructions in a more detailed, step-by-step format.
1. Download your lab resource files and log in to JIRA:

a. Getting access to JIRA for this class and accessing any lab resources
files is explained in the PDF file Accessing Atlassian in CloudShare.
You should have received this document as part of your class
registration process.
b. Log in to JIRA as the Administrator (admin/Charlie!).
c. You see the default System Dashboard.
2. Access the JIRA Administration pages:

a. You can access the JIRA Administration pages in a couple of ways.
Navigate to the JIRA Applications > Versions & licenses administration
page using one of these methods:
i. Click the gear icon on the right side of the JIRA banner. Select
the Administration section you want to go to, in this case
Applications. And then you can select the page in that section
you want. In this case, you don't need to select Versions &
licenses as this is the first page.

ii. Or, a shortcut is to type . (period) or gg, which will bring up a
search dialog, then type the name of the page you want to go to.
Type versions then simply press return or click Versions &
licenses.
If the dialog says 'No Matches' you may either have entered the name
incorrectly or your VM session has timed out. Click the reload icon in the
browser to resume your VM.
You may be wondering why you were asked for your password again.
This is because JIRA protects access to its administrative functions by
requiring a secure administration session. When a JIRA administrator
(who is logged into JIRA) attempts to access an administrative function,
they are prompted to log in again.
b. You may see a message recommending you perform a re-index. This

message appears when major configuration changes are made which
can cause the search index to become out of sync with JIRA's
configuration. This can affect searching for issues. There are no issues
created yet on your instance but it's a good idea to perform the re-index
when you see the message. You see it now because of the way the
classroom virtual machines are created. If you see the message:

i. Click perform a re-index.
ii. On the Indexing administration page in the Re-Indexing section,

click Re-Index.
iii. Once the re-indexing is complete click Acknowledge.

iv. Return to the Versions & licenses administration page.

3. Verify the installed and licensed JIRA applications as well as the user count by
viewing the Versions & licenses page.
You may see out of date or incompatibility warnings something like the
screenshot below. This is because JIRA checks versions dynamically and
alerts you if new versions are available. Also the version numbers may be
slightly different from what's shown above.
Do not upgrade or install new versions! The versions that this

course VM was created with will work for these labs.
What applications are installed and licensed?
Answer: JIRA Service Desk, JIRA Software, and JIRA Core are installed
and licensed.

How many users are licensed and how many already used for JIRA
Software?
Answer: 100 users are licensed and 1 user license is already used (by
the JIRA administrator user, admin).
When does your maintenance expire for JIRA Service Desk?
Answer: View the date next to Maintenance expires.
4. Integrate Confluence with JIRA:

a. One of the most common integrations is JIRA and Confluence. They are
typically installed together and Teams In Space has done so.
b. Navigate to the Application links administration page.
Either type . (period) then Application links or in the Applications

section, under INTEGRATIONS, click Application links.
c. To get the Confluence URL, copy the DNS name from your address field
in your browser i.e. everything before the port number. For example,
uvo1w6mm7awmkst8v0.env.cloudshare.com.
d. Paste this into the Application field then add the remaining part of the
URL including the Confluence port number and application name in the
following format:
http://<DNS _name>:8010/confluence
e. Click Create new link.

f. On the Link applications dialog, leave the defaults and click Continue.
g. You are now redirected to Confluence to create the reciprocal link. Log in
as the Administrator, admin/Charlie!. Since you are accessing an
administrative function, enter the password again.

h. In the Link applications dialog in Confluence, click Continue.
i. You are now redirected back to JIRA and it completes the configuration
of the link. You should see a message that the link was created
successfully. (You may need to wait a minute for this to appear.) If not,
edit the link and double check the spelling and format of the URL.
j. There's one more step you need to do because in our training

environment, we have the VMs set up with the same base URLs. In our
setup the only difference between the JIRA and Confluence base URL is
the port number.
For production installations, set up JIRA and Confluence on separate

servers.

k. Click the Edit link to edit the Confluence application link.
l. Click Outgoing Authentication, select the OAuth tab then check

Enable outgoing 2-Legged OAuth with Impersonation. Click Update.
You can ignore the message that appears.
m. Click Incoming Authentication and if a dialog pops up asking you to

confirm you want to leave the page, click Leave Page.
n. On the Incoming Authentication page, click the OAuth tab, check Allow
user impersonation through 2-Legged OAuth. Click Update.

o. Click Close to close the Configure Confluence dialog.
5. Verify Confluence integration:
Do you notice anything different about the JIRA header at the top of the
page?
Answer: Now you see the application navigator icon (three horizontal
bars) on the left side of the JIRA header.
a. Click the application navigator icon and select Confluence.
b. This takes you to Confluence.
c. Click the application navigator icon again and select JIRA to return to
JIRA.
Now your users can easily move between JIRA and Confluence, create
Confluence pages from within JIRA, and create JIRA issues from
Confluence.
d. Navigate to the Application Navigator administration page (under

Applications).
Here you see an entry for Confluence. When you create an application
link, JIRA automatically adds it to the Application Navigator. Here you

can add links to any other applications your users need quick access to
by providing a name and the URL. You can also restrict access to certain
groups of users. And you can specify the order of the links.
6. Install an Add-on:
a. Navigate to the Manage add-ons administration page.
Either click the Add-ons tab or type '.' (period) then manage
add-ons.
b. View the add-ons that are pre-installed. Here you can install, update,
enable, and disable add-ons.
You may see options to update various add-ons. This is because JIRA
checks versions dynamically and alerts you if new versions are available.
Don't update any add-ons.
c. You can view add-ons in different ways. By default it shows user-

installed add-ons. Click the drop down and select All add-ons.
d. Find just the Hipchat add-ons by typing hipchat in Filter visible add-ons.

e. Navigate to the Find new add-ons page by clicking Find new add-ons
either at the top of this page or on the left navigation menu.
Here you can find and discover add-ons via the Atlassian Marketplace.
All the ones you see are compatible with your JIRA version.
How can you find the most popular add-ons that are free?
Answer: Select Most popular from the first dropdown and select All
free from the last dropdown.

f. The JIRA Calendar Plugin looks like it would make it easier for your users
to enter dates. Click Install in the JIRA Calendar Plugin add-on.
g. Wait while the add-on installs. When it's complete you'll see a dialog that
it's installed and ready to go!
h. Close the dialog.

i. Navigate to the Manage add-ons page and search for JIRA Calendar.

j. Expand the plugin header.
Here you see information about the add-on and this is where you can
uninstall or disable the add-on.
Exercise 2 – Configuring the User Interface

the next page.
1. Configure the look and feel of your JIRA instance:

a. One of your first tasks is to brand JIRA with the Teams In Space look and
feel. Navigate to the Look and feel administration page.
b. Notice that the current logo is the JIRA logo, which appears in the top
header.
c. Let's brand our instance for Teams In Space. You will use the logo file,
TIS.png, you downloaded from the Lab File Resources page to your local
drive in the first exercise. If you did not complete this step, return to
Exercise 1, step 1 and download the file.
d. In the Logo section, upload TIS.png.
What changed?
Answer: The Teams In Space logo now appears in the top banner on the
left and the header itself has changed color. JIRA automatically updates
the color scheme to match your logo.
You can also manipulate individual colors in the Colors section lower
down on this page.
e. Scroll down and choose to show the Site Title. Now you see the instance
name, JIRA, next to your logo.

f. If you like the new look and feel, keep it. Or, you can revert to the
defaults:
i. Reset the logo to the default.
ii. Choose not to show the Site Title.
iii. In the Colors section, if there are any Revert buttons next to any
of the colors, revert these back to the defaults.
2. Customize the default dashboard:

a. Navigate to the System dashboard page. This is the default dashboard
users will see when they log in. It already has three gadgets by default.
b. Add the Favorite Filters gadget.
c. Customize the Favorite Filters gadget by unchecking Show issue
counts since this may impact performance.
Your users will automatically see their favorite filters in this gadget.
d. Move the Favorite Filters gadget so it's below the Introduction gadget.
e. To validate your changes, log out then log back in again as the
Administrator (admin/Charlie!).
Who will see this Dashboard?

Answer: Every user will see this dashboard by default when they log in.
1. Configure the look and feel of your JIRA instance:
a. One of your first tasks is to brand JIRA with the Teams In Space look and
feel. Navigate to the Look and feel administration page (under System).
b. Notice that the current logo is the JIRA logo, which appears in the top
header.
c. Let's brand our instance for Teams In Space. You will use the logo file
you downloaded from the Lab File Resources page to your local drive in
the first exercise. If you did not complete this step, return to Exercise 1,
step 1 and download the file.

d. In the Logo section, click Browse.
e. Browse to the location on your local drive where you saved the lab
resource files and double click TIS.png.
f. Click Upload Logo.
What changed?
Answer: The Teams In Space logo now appears in the top banner on the
left and the header itself has changed color. JIRA automatically updates
the color scheme to match your logo.
You can also manipulate individual colors in the Colors section lower
down on this page.
g. Scroll down and for Site Title, check Show Site Title and click Update.
Now you see the instance name, JIRA, next to your logo.
h. If you like the new look and feel, keep it. Or, you can revert to the
defaults:
i. In the Logo section, click Reset to Default next to the new logo.

ii. Uncheck Show Site Title and click Update.
iii. In the Colors section, if there are any Revert buttons next to any
of the colors, click each of the Revert buttons.
For the rest of this Lab Workbook the screenshots will reflect the default
look and feel.
2. Customize the default dashboard:

a. Navigate to the System dashboard page (under System > USER
INTERFACE). This is the default dashboard users will see when they log
in. It already has three gadgets by default.
b. Click Add Gadget.
c. Click Load all gadgets.
d. Add a gadget that would be useful to users, for example, Favorite

Filters. Click Add gadget next to the Favorite Filters gadget.

e. Click X to exit the Add a gadget dialog.
f. Let's customize the Favorite Filters gadget by unchecking Show issue
counts since this may impact performance.
g. Click Save.
Your users will automatically see their favorite filters in this gadget.
h. We'd like the JIRA Introduction gadget to be at the top of the left column
so move the Favorite Filters gadget down by clicking its header and
dragging it down below the Introduction gadget.
3. To validate your changes, log out by clicking your profile on the far right of the
JIRA header and clicking Log Out. Then log back in again as the Administrator
(admin/Charlie!).

Who will see this Dashboard?
Answer: Every user will see this dashboard by default when they log in to JIRA.
Exercise 3 – Log Files, Auditing & Support Tools

the next page.
1. Locate the JIRA log and configure auditing:

a. If something goes wrong with your JIRA instance one of the first places
to look is the application log file so it's important to know where this is
located. Navigate to the System info administration page and view the
File Paths section.
Where is the JIRA application log, atlassian-jira.log, stored?
Answer: By default it's stored in /var/atlassian/application-data/jira/log.
b. Another tool to aid you in troubleshooting is auditing. Navigate to the

Audit Log administration page Here you see the key activities in JIRA.
What is the most recent activity? Note your audit log may look different.
Answer: Application licenses were updated by admin.
c. Navigate to Audit Log Settings (under Actions).

d. Teams In Space has decided that they only need to retain audit logs for 6
months. Change the retention period to 6 months.
Note the message that any events older than your selected retention
period will be deleted. Before changing this setting ensure you are
following your company retention policies.

e. You can also hide events triggered by your LDAP external directory.
Leave that at the default and save.
2. Use Support Tools to create a Support zip file:

a. Sometime you may need to go to Atlassian Support to resolve an issue.
JIRA comes with a number of Support Tools. Creating a Support zip is
one of these tools that can aid in troubleshooting.
b. Navigate to the Support Tools administration page and create a Support
zip file using the defaults.
Will this zip automatically be sent to Atlassian Support?
Answer: No, you need to send it yourself. You may also want to create
this zip to share with others at your company or for offline debugging.
c. Navigate to the Create Support Request tab.
Here you can create your support request and collect and send the data
all in one step. Do not click Send on this page.
1. Locate the JIRA log and configure auditing:
a. If something goes wrong with your JIRA instance one of the first places
to look is the application log file so it's important to know where this is
located. Navigate to the System info administration page (under
System).
b. Scroll down to the File Paths section.
Where is the JIRA application log, atlassian-jira.log, stored?
Answer: By default it's stored in /var/atlassian/application-data/jira/log.
c. Another tool to aid you in troubleshooting is auditing. Navigate to the

Audit Log administration page (under System). Here you see the key
activities in JIRA.

What is the most recent activity? Note your audit log may look different.
Answer: Application licenses were updated by admin.
d. Click Actions then Audit Log Settings.
e. Teams In Space has decided that they only need to retain audit logs for 6
months. Click the retention period dropdown and select 6 months.
Note the message that any events older than your selected retention
period will be deleted. Before changing this setting ensure you are
following your company retention policies.

f. You can also hide events triggered by your LDAP external directory.
Leave that at the default and click Save.
2. Use Support Tools to create a Support zip file:

a. Sometime you may need to go to Atlassian Support to resolve an issue.
JIRA comes with a number of Support Tools. Creating a Support zip is
one of these tools that can aid in troubleshooting.
b. Navigate to the Support Tools administration page (under System).

c. Click the Create Support Zip tab.
Will this zip automatically be sent to Atlassian Support?
Answer: No, you need to send it yourself. You may also want to create
this zip to share with others at your company or for offline debugging.
d. You can select what to include in the zip. Let's leave it at the default,
which includes all the information listed. Click Create.

e. Wait for it to complete.
f. Click the Create Support Request tab.
Here you can create your support request and collect and send the data
all in one step. Do not click Send on this page.

Optional Exercise 4 – Exploring Configuration Settings
the next page.
1. Explore public signup settings:

a. Navigate to the General configuration administration page Here you see
many general settings related to your JIRA instance.
b. Edit the settings and view the Mode setting.
This mode setting applies to JIRA Software and JIRA Core. We'll cover
the JIRA Service Desk public signup setting next.
What is the default setting for Mode and what does it mean?
Answer: The mode is set by default to Private, which means that only
administrators can create new users.
What does Public mode mean and what things should you consider
before setting this?
Answer: Public mode means that users can sign themselves up for
accounts. You should consider the number of users your license
supports when deciding whether to enable this. Public Mode does not
impact whether said users have access to any projects or not. Project
access is controlled with project permissions. (We'll cover project
permissions later in the course.) The Mode setting only controls whether
users can create their own accounts or not.
c. View the CAPTCHA on signup setting.
Can you show a CAPTCHA image on signup if Mode is set to Private?
Answer: No, the CAPTCHA image is only shown on signup if Mode is set
to Public and CAPTCHA on signup is set to ON.
d. Now lets look at the public signup settings for Service Desk. Navigate to
the JIRA Service Desk configuration administration page and view
Public signup.
To turn on public signup for Service Desk you first click the Turn it on
button here. Then in the Service Desk project's administration you
specify that anyone can sign up for a customer account on my Customer
Portal. We don't have any projects yet so this is a step you or the Service

Desk project administrator would perform when the project is created (if
you wanted public signup).
e. Leave it at the default of public signup Off.
2. Explore the default language setting:

a. Navigate to the General configuration administration page and edit the
settings.
b. View the Internationalization section.
What is the default language?
Answer: English (United States).
c. View the other languages that are installed that you could use for your
default language. Teams In Space is headquartered in America so we will
keep the default language. Cancel out of this page.
3. Explore time tracking:

a. Navigate to the Time tracking administration page.
b. To make any changes you first have to Deactivate time tracking, then
reactivate it after the change. You won't lose any existing time tracking
data by disabling/re-enabling time tracking. Deactivate time tracking.
c. Now you can configure the hours per day, days per week, time format,
and so on. We'll leave the settings at the default. Turn time tracking back
on.
Congratulations on completing the lab!
1. Explore public signup settings:
a. Navigate to the General configuration administration page (under
System). Here you see many general settings related to your JIRA
instance.
b. Click Edit Settings.
c. View the Mode setting.
This mode setting applies to JIRA Software and JIRA Core. We'll cover
the JIRA Service Desk public signup setting next.

What is the default setting for Mode and what does it mean?
Answer: The mode is set by default to Private, which means that only
administrators can create new users.
What does Public mode mean and what things should you consider
before setting this?
Answer: Public mode means that users can sign themselves up for
accounts. You should consider the number of users your license
supports when deciding whether to enable this. Public Mode does not
impact whether said users have access to any projects or not. Project
access is controlled with project permissions. (We'll cover project
permissions later in the course.) The Mode setting only controls whether
users can create their own accounts or not.
d. View the CAPTCHA on signup setting.
Can you show a CAPTCHA image on signup if Mode is set to Private?
Answer: No, the CAPTCHA image is only shown on signup if Mode is set
to Public and CAPTCHA on signup is set to ON.
e. Scroll to the bottom of the page and click Cancel so no changes are
made.
f. Now lets look at the public signup settings for Service Desk. Navigate to
the JIRA Service Desk configuration page (under Applications > JIRA
SERVICE DESK).
g. Scroll down and view Public signup.

To turn on public signup for Service Desk you first click the Turn it on
button here. Then in the Service Desk project's administration you
specify that anyone can sign up for a customer account on my Customer
Portal. We don't have any projects yet so this is a step you or the Service
Desk project administrator would perform when the project is created (if
you wanted public signup).
h. Leave it at the default of public signup Off.
2. Explore the default language setting:

a. Return to the General configuration administration page.
b. Click Edit Settings.
c. Scroll down to the Internationalization section.
What is the default language?
Answer: English (United States).
d. Click the drop down for Default language and view the other languages
that are installed that you could use for your default language. Teams In
Space is headquartered in America so we will keep the default language.
e. Scroll to the bottom of the page and click Cancel so no changes are
made.
3. Explore time tracking:

a. Navigate to the Time tracking administration page (under Issues).

b. To make any changes you first have to Deactivate time tracking, then
reactivate it after the change. You won't lose any existing time tracking
data by disabling/re-enabling time tracking. Click Deactivate.
c. Now you can configure the hours per day, days per week, time format,
and so on. We'll leave the settings at the default. Click Activate to turn
time tracking back on.

Lab 2 Appendix
Further reading
Reference URL
Administering http://go.atlassian.com/admin_jira7_server
JIRA
Applications
Best Practices
Pitfall Example Use Case Best Practice
Not easy to switch Users are complaining they have to Integrate JIRA and
between JIRA and open a new browser window and Confluence, which
other commonly go to Confluence separately from creates an application
used applications. JIRA. link. Also create
application links for other
commonly used
applications.
Lost auditing You set the auditing retention Before changing the
records. period to 1 month but the company auditing retention period
policy is 6 months. A configuration ensure you are following
change was made 6 weeks ago your company retention
that negatively affected the policies.
installation but now you have no
record of who did it.
You cannot Performance has suddenly Use the Support Tools to

successfully degraded and you cannot figure create a zip and send it to
resolve a problem out why. Atlassian Support.
with your JIRA
instance.

Lab 3 – Setting Up Users & Groups
Scenario
Teams In Space stores their users in an LDAP server. In JIRA, the LDAP user repository
has already been set up so the LDAP users and groups exist in JIRA. You now need to
give users access to the JIRA applications they will be using. Here are some of the
groups that exist in LDAP and which JIRA default groups you will map them to:
LDAP Group JIRA Group JIRA Application

Human Resources jira-core-users JIRA Core
Development jira-software-users JIRA Software
Customer Service jira-servicedesk-users JIRA Service Desk
As the default JIRA administrator, admin, you perform the following tasks:
• Explore the user directories
• Synchronise the LDAP user directory
• Set up application access for JIRA administrators
• Add LDAP group members to JIRA default groups
• Create a new user
• Optional:
o Deactivate a user
o Troubleshoot a user login issue
o Explore default settings for application access
Exercise 1 – Exploring User Directories

If you would prefer to follow step-by-step instructions, go to Detailed Instructions
on page 37.
1. Log in to JIRA as the Administrator (admin/Charlie!).

2. Navigate to the User Directories administration page and view the settings for
the default JIRA Internal Directory and the LDAP server.
Will users or groups created in JIRA be written to the LDAP Server? Why
or why not?
Answer: The LDAP server is set up as Read Only, with Local Groups so
no new users or groups created in JIRA will be written to LDAP. We
don't want Read/Write as LDAP is our source of truth for user
management. But we can still create groups in JIRA to manage
permissions, etc. (Permissions will be covered in the next module.)
1.
When was the LDAP server last synchronized?

Answer: Look at the date of the last synchronization under the
Synchronise link.
If you make changes to the directory and you want the changes to be
picked up immediately, do a manual synchronize rather than wait for
them to be picked up by the next scheduled directory synchronization.
The default synchronization time is once an hour.
3. Perform a manual synchronization and confirm it completed successfully.
4. View the directory order.
If a user tries to log in, which directory will be searched first for
authentication?
Answer: The JIRA Internal Directory will be searched first as it's first in
the list of user directories.
5. Change the directory order so the LDAP server is first.
What happened?
Answer: You got an error that you cannot move the directory without
losing your system admin privileges.
Why do you think this occurred?
Answer: You weren't able to reorder the user directories because there
is a user in LDAP with the same name (admin) as you, the
Administrator. But that user does not have administrator permission on
JIRA. The solution is either to leave the order as is with the JIRA Internal
Directory first. Or ensure there is a group on LDAP that contains that
user then give that group administrator permission on JIRA. We'll leave
the order as is with the JIRA Internal Directory fist.

1. Log in to JIRA as the Administrator (admin/Charlie!).
2. Navigate to the User Directories administration page (under User
management).
Type . (period) and enter user directories. Or click the gear icon and select
User management, and then select the User Directories page.
3. View the settings for the default JIRA Internal Directory and the LDAP server.
Will users or groups created in JIRA be written to the LDAP Server?

Why or why not?
Answer: The LDAP server is set up as Read Only, with Local Groups so
no new users or groups created in JIRA will be written to LDAP. We
don't want Read/Write as LDAP is our source of truth for user
management. But we can still create groups in JIRA to manage
permissions, etc. (Permissions will be covered in the next module.)
1.
When was the LDAP server last synchronized?
Answer: Look at the date of the last synchronization under the

Synchronise link.
If you make changes to the directory and you want the changes to be
picked up immediately, do a manual synchronize rather than wait for
them to be picked up by the next scheduled directory synchronization.
The default synchronization time is once an hour.
4. Perform a manual synchronization by clicking Synchronise. Wait for it to finish

and ensure it completed successfully.

5. View the directory order.
If a user tries to log in, which directory will be searched first for
authentication?
Answer: The JIRA Internal Directory will be searched first as it's first in
the list of user directories.
6. Click the Up arrow in the Order column of the LDAP server row to change the
directory order.
What happened?
Answer: You got an error that you cannot move the directory without
losing your system admin privileges.
Why do you think this occurred?
Answer: You weren't able to reorder the user directories because there
is a user in LDAP with the same name (admin) as you, the
Administrator. But that user does not have administrator permission on
JIRA. The solution is either to leave the order as is with the JIRA Internal
Directory first. Or ensure there is a group on LDAP that contains that
user then give that group administrator permission on JIRA. We'll leave
the order as is with the JIRA Internal Directory fist.

Exercise 2 – Exploring Users and Groups
page 43.
1. Continuing as the Administrator (admin/Charlie!), navigate to the Users

administration page.
2. Review the existing users then answer the questions below.
Which user directory are most of the users from? Are there any users
from the JIRA Internal Directory?
Answer: Since LDAP is where Teams In Space store their user and
groups; most of the users are from the LDAP user directory. There is
only one user from the JIRA Internal Directory – the System
Administrator, admin, that was created at installation.
Have any of the LDAP users logged in yet?
Answer: No, under Login details it indicates they have never logged in.
What groups that exist in LDAP were created in JIRA?
Answer: Customer Service, Development, Human Resources, and IT.
Why don't you see an Edit link for Ryan Lee?
Answer: Because his user account resides in LDAP and the LDAP user
repository is set up as Read Only, With Local Groups. The Read Only
part of that restricts Edit and Delete from JIRA. The With Local Groups
part allows you to assign LDAP users to groups created in JIRA.
3. Test user access:

a. Log out as admin and log in as Ryan Lee (rlee/Charlie!).
Why can't Ryan log in?
Answer: Because he is not yet a member of any group that is

associated with a JIRA application. The LDAP groups were simply
created in JIRA. You still need to configure application access.
You can set up the LDAP user directory with default group
memberships, for example, jira-servicedesk-users, but this would mean
that all LDAP users would become a member of that group or groups.
For Teams In Space, we want to separate users into different JIRA

applications so we did not use any default group memberships when
setting up the LDAP User Directory.
b. Log back in as the JIRA administrator (admin/Charlie!).
4. Set up application access for JIRA administrators:

a. Navigate to the Application access administration page.
What groups allow access to which JIRA applications?
Answer: The jira-servicedesk-users group allows access to JIRA Service

Desk, the jira-software-users group and the jira-administrators group
allow access to JIRA Software, and the jira-core-users group allows
access to JIRA Core.
Notice that the jira-administrators group is only added to JIRA Software.
This is because JIRA Software was the first application installed. When
further applications are installed jira-administrators is not added
automatically.
Being an administrator means you have access to the administration

pages and can change settings and create projects. But to be able to
view or work in projects you need to be in a group that has the
appropriate application access. It's up to your organization and its
policies whether or not to allow Administrators application access.
Teams In Space has decided it would like JIRA administrators to have
access to all applications. This may not be the case for all organizations.
Some may want to prevent Administrators from seeing the actual content
and so prevent mistakes with the data.
b. Add the jira-administrators group to both JIRA Service Desk and JIRA
Core.
c. Now administrators have access to all the features and functions of each
JIRA application. Note the MULTI-APP-ACCESS lozenge for them.
How many default groups does each JIRA application have now?
Answer: Each JIRA application has only one default group – notice the
one that is checked under the Default column.
You wouldn't want to make the jira-administrators group a default group

for an application, for example JIRA Core, as that would mean that any
new users that were created and given access to JIRA Core would
automatically be a member of the jira-administrators group too!
5. Explore groups:
a. Navigate to the Groups administration page (under User management).
Notice that some of the Delete links are greyed out.

Why can't you delete the jira-servicedesk-users group?
Answer: Because this is the only default group for JIRA Service Desk.
Each JIRA application needs to have at least one default group to assign
users to when they are given application access.
Why can't you delete the jira-administrators group?
Answer: Because this is the only group that grants you system
administration privileges. JIRA needs at least one group to assign system
administration privileges.
Note the lozenges next to some of the group names that indicate either
application access or administrator rights. These let you to quickly tell
what groups have what access. For example jira-servicedesk-users have
access to JIRA SERVICE DESK and jira-administrators have ADMIN
access and also access to multiple applications.
b. Delete the IT group.
What happened?
Answer: You couldn't delete the group because it exists in the LDAP
user directory and is synchronised from there in JIRA. And the LDAP
user directory is set up as Read Only, With Local Groups. The only
groups you can delete are groups that were created locally in JIRA (that
are also not the sole default group for an application).
6. Add LDAP group members to JIRA default groups:
All our new LDAP users are only members of the groups originally
created in LDAP (Human Resources, Development, Customer Service,
and IT). How do we give them access to JIRA applications?
Answer: There are two ways we could do this:

i. Add the LDAP groups to the applications on the Application
access page. But we would still need to add all the permissions
to each of these groups, which would be time consuming.
(Permissions will be covered in the next module.)
ii. A better option is to add the members of the LDAP groups to the
default JIRA application groups as these are already set up with
permissions.
a. Add the members of the LDAP groups to the default JIRA application
groups, using the table below as a guide:

Use the User Picker icon to find the members of each group.
Note: We will deal with the members of the IT group

(Administrators) in the next module's lab.
b. Navigate back to the Groups page. Check the number of users you have
with the screenshot below.
7. Test user access to JIRA applications:

a. Log out as admin and log in as Ryan Lee again (rlee/Charlie!).
Was he successful this time?
Answer: Yes, he was successful because he is now a member of a group

that allows access to a JIRA application.
b. To sign on as a new user, leave the language at the default of English

(United States), skip choosing an avatar and then skip the quick tour.
c. Now you see the default System dashboard that you customized in the
last lab.
What JIRA application menu options does Ryan see on the left side of
the JIRA header next to the Application navigator and the JIRA name and
symbol?
Answer: Ryan sees Dashboards, Capture, and Boards. He sees Boards

because he's a JIRA Software user. (Capture is an add-on.)
d. Log out as Ryan and log in as Luis Beck (lbeck/Charlie!).

Look at the JIRA header – why is what he sees different from what Luis
sees?
Answer: He sees Dashboards and Capture but not Boards because

he's a Core user.
Each user experience is customized depending on which JIRA

application they have access to.
1. Continuing as the Administrator (admin/Charlie!), navigate to the Users
administration page (under User management).
2. Review the existing users and answer the questions below.
Which user directory are most of the users from? Are there any users
from the JIRA Internal Directory?
Answer: Since LDAP is where Teams In Space store their user and
groups; most of the users are from the LDAP user directory. There is
only one user from the JIRA Internal Directory – the System
Administrator, admin, that was created at installation.
Have any of the LDAP users logged in yet?
Answer: No, under Login details it indicates they have never logged in.
What groups that exist in LDAP were created in JIRA?
Answer: Customer Service, Development, Human Resources, and IT.

Why don't you see an Edit link for Ryan Lee?
Answer: Because his user account resides in LDAP and the LDAP user
repository is set up as Read Only, With Local Groups. The Read Only
part of that restricts Edit and Delete from JIRA. The With Local Groups
part allows you to assign LDAP users to groups created in JIRA.
3. Test user access:

a. Log out as admin and log in as Ryan Lee (rlee/Charlie!).
Why can't Ryan log in?
Answer: Because he is not yet a member of any group that is

associated with a JIRA application. The LDAP groups were simply
created in JIRA. You still need to configure application access.
You can set up the LDAP user directory with default group
memberships, for example, jira-servicedesk-users, but this would mean
that all LDAP users would become a member of that group or groups.
For Teams In Space, we want to separate users into different JIRA
applications so we did not use any default group memberships when
setting up the LDAP User Directory.
b. Log back in as the JIRA administrator (admin/Charlie!).
4. Set up application access for JIRA administrators:

a. Navigate to the Application access administration page (under
Applications).
What groups allow access to which JIRA applications?

Answer: The jira-servicedesk-users group allows access to JIRA
Service Desk, the jira-software-users group and the jira-administrators
group allow access to JIRA Software, and the jira-core-users group
allows access to JIRA Core.
Notice that the jira-administrators group is only added to JIRA
Software. This is because JIRA Software was the first application
installed. When further applications are installed jira-administrators is
not added automatically.
Being an administrator means you have access to the administration
pages and can change settings and create projects. But to be able to
view or work in projects you need to be in a group that has the
appropriate application access. It's up to your organization and its
policies whether or not to allow Administrators application access.
Teams In Space has decided it would like JIRA administrators to have
access to all applications. This may not be the case for all
organizations. Some may want to prevent Administrators from seeing
the actual content and so prevent mistakes with the data.
b. Add the jira-administrators group to both JIRA Service Desk and JIRA
Core by clicking the Select group dropdown below each application and
selecting jira-administrators.

Now administrators have access to all the features and functions of each
JIRA application. Note the MULTI-APP-ACCESS lozenge for them.
How many default groups does each JIRA application have now?
Answer: Each JIRA application has only one default group – notice
the one that is checked under the Default column.
You wouldn't want to make the jira-administrators group a default

group for an application, for example JIRA Core, as that would mean
that any new users that were created and given access to JIRA Core
would automatically be a member of the jira-administrators group too!

5. Explore groups:
a. Navigate to the Groups administration page (under User management).
Notice that some of the Delete links are greyed out.
Why can't you delete the jira-servicedesk-users group?
Hover mouse over greyed out delete link.
Answer: Because this is the only default group for JIRA Service Desk.
Each JIRA application needs to have at least one default group to assign
users to when they are given application access.
Why can't you delete the jira-administrators group?
Answer: Because this is the only group that grants you system
administration privileges. JIRA needs at least one group to assign system
administration privileges.
Note the lozenges next to some of the group names that indicate either
application access or administrator rights. These let you to quickly tell
what groups have what access. For example jira-servicedesk-users have
access to JIRA SERVICE DESK and jira-administrators have ADMIN
access and also access to multiple applications.
b. Click Delete for the IT group.
c. Click Delete again.
What happened?

Answer: You couldn't delete the group because it exists in the LDAP
user directory and is synchronised from there in JIRA. And the LDAP
user directory is set up as Read Only, With Local Groups. The only
groups you can delete are groups that were created locally in JIRA (that
are also not the sole default group for an application).
d. Click Cancel.
6. Add LDAP group members to JIRA default groups:
All our new LDAP users are only members of the groups originally
created in LDAP (Human Resources, Development, Customer Service,
and IT). How do we give them access to JIRA applications?
Answer: There are two ways we could do this:

i. Add the LDAP groups to the applications on the Application
access page. But we would still need to add all the permissions
to each of these groups, which would be time consuming.
(Permissions will be covered in the next module.)
ii. A better option is to add the members of the LDAP groups to the
default JIRA application groups as these are already set up with
permissions.
a. In the jira-software-users row on the Groups page, click Edit

members.
b. Under or next to Add members to selected group(s), click the user

picker icon.

c. In the User Picker dialog, click the In group dropdown and select
Development.
d. Click Filter to return just the eight users in the Development group. Then
click the checkbox at the top of the list to select all users and then click
Select.

e. Back on the Bulk edit group members page, click Add selected users.
You should now see all the Development users in the jira-software-users
group.
f. Click the x next to jira-software-users group then enter jira-core and

select the jira-core-users group. Click refresh the group members list.

You should now only see admin as the group member.
g. Repeat this process (steps b through f) to add the members of the

Human Resources group to the jira-core-users group and the members
of the Customer Service group to the jira-servicedesk-users group. Use
the table and screenshots below for reference.
LDAP Group JIRA Group

Human Resources jira-core-users
Development jira-software-users
Customer Service jira-servicedesk-users
Note: We will deal with the members of the IT group (Administrators) in

the next module's lab.

h. Navigate back to the Groups page. Check the number of users you have
with the screenshot below.
7. Test user access to JIRA applications:

a. Log out as admin and log in as Ryan Lee again (rlee/Charlie!).
Was he successful this time?
Answer: Yes, he was successful because he is now a member of a group

that allows access to a JIRA application.
b. Leave the language at the default of English (United States) and click
Continue.
c. Skip choosing an avatar and click Next. Then click Skip quick tour.
d. Now you see the default System dashboard that you customized in the
last lab.

What JIRA application menu options does Ryan see on the left side of
the JIRA header next to the Application navigator and the JIRA name
and symbol?
Answer: Ryan sees Dashboards, Capture, and Boards. He sees Boards

because he's a JIRA Software user. (Capture is an add-on.)
e. Log out as Ryan and login as Luis Beck (lbeck/Charlie!).

f. As you did for Ryan, click Continue, Next, and Skip quick tour.
Look at the JIRA header – why is what he sees different from what Luis
sees?
Answer: He sees Dashboards and Capture but not Boards because

he's a Core user.
Each user experience is customized depending on which JIRA

application they have access to.
g. Log out as Luis.

Exercise 3 – Creating a New User
the next page.
1. Create a new user:

Even when you're using LDAP for your user repository there may be times
when you want to create a user or users in the JIRA Internal Directory. For
example, a guest user account.
a. Log back in as the Administrator (admin/Charlie!) and navigate to the

Users administration page (under User management).
What are the two ways users can be created from this page?
Answer: Invited or created manually.
b. Teams In Space wants a guest account so create a new user:

a. Email address: guest@teams-in-space.com
b. Full name: Guest
c. Username: guest
d. Password: Leave this field empty
What happens if you don't specify a password?
Answer: One will be generated automatically and the user's

notification email will offer an opportunity to set the password
when the user logs in.
Creating a user manually in JIRA is the only way you can set the
user's password. You cannot do this when you invite a user.
e. Check Send notification email.
To select Send notification email you need to have an Outgoing

Mail server set up (under System). This has already been set up
on your JIRA instance.
a. For application access, leave at the default of JIRA Software.
Note that access to JIRA Service Desk or JIRA Software also

included access to JIRA Core.
2. Review the newly created user.
What group or groups is the user a member of?

Answer: jira-software-users.
When can you add a newly created user to another group? What about a
newly invited user?
Answer: After you have created a user you can immediately add this
user to other groups. If you invite a user, however, the invited user's
account doesn't exist until the invited person completes the account
creation. You have to wait until the account exists to provision that user.
1. Create a new user:
Even when you're using LDAP for your user repository there may be times
when you want to create a user or users in the JIRA Internal Directory. For
example, a guest user account.
a. Log back in as the Administrator (admin/Charlie!) and navigate to the

Users administration page (under User management).
What are the two ways users can be created from this page?
Answer: Invited or created manually.
b. Click Create user. Teams In Space wants a guest account.

c. In the Create new user dialog enter:
b. Email address: guest@teams-in-space.com
c. Full name: Guest
d. Username: guest
e. Password: Leave this field empty
What happens if you don't specify a password?
Answer: One will be generated automatically and the user's

notification email will offer an opportunity to set the password
when the user logs in.
Creating a user manually in JIRA is the only way you can set the
user's password. You cannot do this when you invite a user.
f. Check Send notification email.

To select Send notification email you need to have an Outgoing
Mail server set up (under System). This has already been set up
on your JIRA instance.
g. For application access, leave at the default of JIRA Software.
Note that access to JIRA Service Desk or JIRA Software also

included access to JIRA Core.
h. Click Create user
2. Review the newly created user.
What group or groups is the user a member of?
Answer: jira-software-users.
When can you add a newly created user to another group? What about a
newly invited user?
Answer: After you have created a user you can immediately add this
user to other groups. If you invite a user, however, the invited user's
account doesn't exist until the invited person completes the account
creation. You have to wait until the account exists to provision that user.

Optional Exercise 4 – Deactivating a User & Exploring Access
the next page.
1. Deactivate a user:
Before making a user inactive, remove the user from all groups and roles
they belong to.
a. The guest user has not been assigned any roles yet but we can remove
the user from the group. Remove the guest user from the jira-software-
users group.
b. Now the user is not a member of any groups and so does not have
access to any JIRA applications. Edit the guest user and make it inactive.
c. Notice the guest user's Full name and Username now has a strike
through to show it's inactive.
2. Troubleshoot a user log in issue:

a. William Smith has complained to you that he can't log in. Review his
account settings on the Users page to find and fix the problem.
b. Test logging in as William Smith (wsmith/Charlie!) then log back in as
the Administrator (admin/Charlie!).
What's missing?
Look at his entry on the Users administration page.
Answer: He's not a member of any JIRA group and so does not have
access to any JIRA applications and cannot log in.
William Smith is an Engineering Manager. Which group do you think he

belongs in?
Answer: As an Engineering Manager he would need access to JIRA

Software so he should be placed in the jira-software-users group.
c. Edit William Smith's account and add him to the jira-software-users

group. Now that William Smith is a member of jira-software-users group
he has access to JIRA Software and will be able to log in.
d. Log out as admin and test logging in as William Smith (wsmith/Charlie!).

You should now be successful. Log out as William.
Is there anything else you need to do?

Answer: Yes, let the LDAP Administrator know that William Smith is
missing from the Development group in LDAP.
3. Explore default settings for application access:
When you create a new user you specify which JIRA application(s) they will
have access to. You can either select this explicitly or accept the default
application(s). You set the default application(s) new users are created with
on the Application access page.
a. Log in to JIRA as the Administrator (admin/Charlie!) and navigate to the

Application access administration page.
b. View the defaults for new users.
What application or applications by default will new users have access

to?
Answer: New users will have access to JIRA Software by default. You
can select more than one default here but we'll leave this as just JIRA
Software.
When you create new users you can override this default. When you
have multiple JIRA Applications installed, leave the default to the
application that most of your users will be using.
c. On the Application access page, view the JIRA applications' default

groups. Note which groups are checked in the Default column.
If you create a user and give them access to JIRA Software, which group
or groups will they automatically become a part of?
Answer: They will automatically become a part of the group specified as

the default for that application, jira-software-users.
1. Deactivate a user:
Before making a user inactive, remove the user from all groups and roles
they belong to.
a. The guest user has not been assigned any roles yet but we can remove
the user from the group. Click the ellipses for the Guest user and then
click Edit user groups.

b. Select jira-software-users and then click Leave selected groups.
c. Now the user is not a member of any groups and so does not have
access to any JIRA applications. Click Edit for the Guest user.
d. Uncheck Active and click Update.
e. Scroll down and notice the guest user's Full name and Username now
has a strike through to show it's inactive.

2. Troubleshoot a user log in issue:
a. William Smith has complained to you that he can't log in. Review his
account settings on the Users page to find and fix the problem.
b. Test logging in as William Smith (wsmith/Charlie!) then log back in as
the Administrator (admin/Charlie!).
What's missing?
Look at his entry on the Users administration page.
Answer: He's not a member of any JIRA group and so does not have
access to any JIRA applications and cannot log in.
c. Click the ellipses for William Smith and then click Edit user groups.
William Smith is an Engineering Manager. Which group do you think he

belongs in?
Answer: As an Engineering Manager he would need access to JIRA

Software so he should be placed in the jira-software-users group.
d. Type jira then select jira-software-users from the list of groups that
appear.

e. Click Join selected groups.
f. Now William Smith is a member of jira-software-users group and so has

access to JIRA Software and should be able to log in.
g. Log out as admin and test logging in as William Smith (wsmith/Charlie!).

You should now be successful. Log out as William.
Is there anything else you need to do?
Answer: Yes, let the LDAP Administrator know that William Smith is
missing from the Development group in LDAP.

3. Explore default settings for application access:
When you create a new user you specify which JIRA application(s) they
will have access to. You can either select this explicitly or accept the
default application(s). You set the default application(s) new users are
created with on the Application access page.
a. Log in to JIRA as the Administrator (admin/Charlie!).

b. Navigate to the Application access administration page (under
Applications).
c. Click Set defaults for new users.
What application or applications by default will new users have access

to?
Answer: New users will have access to JIRA Software by default. You
can select more than one default here but we'll leave this as just JIRA
Software.
When you create new users you can override this default. When you
have multiple JIRA Applications installed, leave the default to the
application that most of your users will be using.
d. Click Close.
e. On the Application access page, view the JIRA applications' default
groups. Note which groups are checked in the Default column.

If you create a user and give them access to JIRA Software, which group
or groups will they automatically become a part of?
Answer: They will automatically become a part of the group specified as

the default for that application, jira-software-users.

Lab 3 Appendix
Further reading
Reference URL
Managing http://go.atlassian.com/managing_users
users
Managing http://go.atlassian.com/managing_groups
groups
Best Practices
Users mistakenly You make the jira-administrators group Do not make the jira-
get administrator a default group for JIRA Service Desk. administrators group
privileges. Now any new users that are created a default group for
and given access to JIRA Service Desk any JIRA application.
will automatically be a member of the
jira-administrators group too!

Lab 4 – Configuring Global Permissions
Scenario
Teams In Space wants to ensure the right people have the right global permissions as
these can be very powerful and affect the JIRA instance system-wide. They've decided
to create two separate groups for JIRA system administrators and JIRA administrators
and identified the users who should belong to each group. Also they don't want all
users to be able to bulk change issues. You need to configure the global permissions to
meet these needs.
As various users, you perform the following tasks:

• View global permissions
• Determine which users have what global permissions
• Create a new group for JIRA system administrators
• Configure global permissions for JIRA system administrators and JIRA
administrators
• Assign users to each Administrator group
• Remove the Bulk Change permission from some default groups
• Optional:
o Observe the impact of different permissions by logging in as different
users
o View the difference between JIRA system administrators and JIRA
administrators
Exercise 1 – Configuring Administrator Permissions

page 69.
1. View global permissions:

a. Log in to JIRA as the default System Administrator (admin/Charlie!) and
navigate to the Global permissions administration page.
Which permissions are available only to members of the jira-

administrators group?
Answer: JIRA System Administrators and JIRA Administrators.
b. View users to see which users have the JIRA Administrators permission.
The View Users link takes you to the Users screen, but with the In Group
dropdown selected for the relevant group.
How many users have the JIRA Administrators permission?

Answer: Just one, the admin user. This user is currently the only
member of the jira-administrators group.
2. Create a new group for JIRA system administrators:

In JIRA you can have two administrative roles – the JIRA system
administrator and the JIRA administrator. These are controlled by the JIRA
System Administrators and the JIRA Administrators global permissions. The
JIRA system administrator has the ability to do everything in JIRA; the JIRA
administrator has a slightly smaller set of permissions. At some companies,
the same person or persons may fill the two roles. However at Teams In
Space, they have separated the roles. Mitch Davis is the JIRA system
administrator and Dakota Jones is the JIRA administrator. As they expand,
more people may be assigned these roles as well so we need two groups to
manage these two roles.
Currently we just have the jira-administrators default group, which has both
the JIRA System Administrators and the JIRA Administrators global
permissions assigned to it. Here we'll create a new group, jira-system-
administrators and assign the JIRA System Administrators permission to it
then remove that permission from the JIRA administrators group. We'll also
assign the correct users to each group.
a. Navigate to the Groups administration page.

b. Add a new group called jira-system-administrators.
c. Mitch Davis has been identified as the JIRA system administrator. We
also want the admin user to have all privileges. Add mdavis and admin
user to the jira-system-administrators group.
In a production system, you'd want to have at least two JIRA system

administrators (and JIRA administrators) set up in JIRA even if one
person performs the role. This means someone else can perform the role
when the other person is away.
3. Configure global permissions for JIRA system administrators:

a. Navigate to the Global Permissions administration page view the Add
Permission UI at the bottom. Here you can assign a global permission to
a group.
What do you think the Anyone option means in the context of this UI?
Answer: The Anyone group grants the permission you've chosen to

anyone including non logged-in users.
You should avoid using Anyone with Global Permissions, especially for
public or production instances. Instead, you should use project
permissions to control the access of anonymous users. We'll discuss
that in more detail in a later module.

b. Add the JIRA System Administrators permission to the jira-system-
administrators group.
c. To verify your change, log out as admin and log in as the new JIRA
system administrator, Mitch Davis (mdavis/Charlie!).
There's one more thing you need configure to give this JIRA system
administrator full access to the instance (as requested by Teams In
Space). What is it?
Answer: Note the message that appears and recall from Module 3
that being an administrator means you have access to the
administration pages. But to be able to view or work in projects you
need to be in a group that has the appropriate application access.
We've created the jira-system-administrators group but they don't
have access to any JIRA applications.
d. On the Application access page, add the jira-system-administrators

group to each of the three JIRA applications. Now JIRA system
administrators have access to all the features and functions of each JIRA
application as well as full administrator access.
Even though some organizations may wish the JIRA system

administrators and JIRA administrators to not have access to
applications, they can always add access themselves! So it would
be an honors system.
e. To confirm Mitch's JIRA System Administrators permission, navigate to

the Outgoing Mail administration page and confirm he can edit the
SMTP Server settings. This is something JIRA administrators cannot do.
4. Configure global permissions for JIRA administrators:

Dakota Jones has been identified as the JIRA administrator so Mitch can
now set her up.
a. Continuing as Mitch Davis (mdavis/Charlie!), the new System

Administrator, navigate to the Groups administration page and add
Dakota Jones to the jira-administrators group:
Were you able to do this? If not, why not?
Answer: We gave the jira-system-administrators group the JIRA

System Administrators permission but we did not give the group
any other global permissions. So Mitch doesn't have the
permission to browse users.
i. Log out as Mitch and log back in as the default System

ii. Navigate to the Global Permissions administration page and use
the Add Permission UI to add the remaining global permissions to
the jira-system-administrators group:
• Browse Users
• Create Shared Objects
• Manage Group Filter Subscriptions
• Bulk Change
b. Now we can continue on the task to add Dakota Jones to the JIRA
administrators group. Log out as admin and log back in as Mitch Davis
(mdavis/Charlie!) and return to the Groups administration page.
c. Add Dakota Jones (djones) to the jira-administrators group.
There's one more task Mitch needs to do to ensure Dakota has the
right permissions as a JIRA administrator (and not a JIRA system
administrator). Do you know that that is?
Answer: Mitch needs to remove the JIRA System Administrators

permission from the jira-administrators group.
d. Navigate to the Global Permissions administration page, and remove

the jira-administrators group from the JIRA System Administrators
permission.
e. Back on the Global Permissions page confirm you now only have the
JIRA System Administrators permission for the jira-system-
administrators group the JIRA Administrators permission for the jira-
5. Verify Dakota's JIRA Administrators permission by logging out and back in as

Dakota (djones/Charlie!) and navigating to the Outgoing Mail administration
page (under System).
Can she see view and configure the SMTP Server?
Answer: No, she can only disable outgoing mail, which is all she
should be able to do as a JIRA administrator.

1. View global permissions:
a. Log in to JIRA as the default System Administrator (admin/Charlie!).
b. Navigate to the Global permissions administration page (under System).
Which permissions are available only to members of the jira-

administrators group?
Answer: JIRA System Administrators and JIRA Administrators.
c. To see which users have the JIRA Administrators permission, click View
Users in the JIRA Administrators row,
The View Users link takes you to the Users screen, but with the In Group
dropdown selected for the relevant group.

How many users have the JIRA Administrators permission?
Answer: Just one, the admin user. This user is currently the only
member of the jira-administrators group.
2. Create a new group for JIRA system administrators:

In JIRA you can have two administrative roles – the JIRA system
administrator and the JIRA administrator. These are controlled by the JIRA
System Administrators and the JIRA Administrators global permissions. The
JIRA system administrator has the ability to do everything in JIRA; the JIRA
administrator has a slightly smaller set of permissions. At some companies,
the same person or persons may fill the two roles. However at Teams In
Space, they have separated the roles. Mitch Davis is the JIRA system
administrator and Dakota Jones is the JIRA administrator. As they expand,
more people may be assigned these roles so we need two groups to
manage these two roles.
Currently we just have the jira-administrators default group, which has both
the JIRA System Administrators and the JIRA Administrators global
permissions assigned to it. Here we'll create a new group, jira-system-
administrators and assign the JIRA System Administrators permission to it
then remove that permission from the JIRA administrators group. We'll also
assign the correct users to each group.
a. Navigate to the Groups administration page (under User Management).

b. Under Add group enter jira-system-administrators for the Name and
click Add group.
c. In the jira-system-administrators' row, click Edit members.
d. Mitch Davis has been identified as the JIRA system administrator. We

also want the default admin user to have all privileges. Add these users
to the jira-system-administrators group:
i. Click the User Picker icon under Add members to selected
group(s).

ii. Select admin and mdavis and click Select.
iii. Click Add selected users. You now see the two users as group
members of the jira-system-administrators group.

In a production system, you'd want to have at least two JIRA
system administrators (and JIRA administrators) set up in JIRA
even if one person performs the role. This means someone else
can perform the role when the other person is away.
3. Configure global permissions for JIRA system administrators:

a. Navigate to the Global Permissions administration page (under System)
and scroll down the page to the Add Permission UI. Here you can
assign a global permission to a group.
What do you think the Anyone option means in the context of this UI?
Answer: The Anyone group grants the permission you've chosen to

anyone including non logged-in users.
You should avoid using Anyone with Global Permissions, especially for
public or production instances. Instead, you should use project
permissions to control the access of anonymous users. We'll discuss
that in more detail in a later module.
b. For Permission choose JIRA System Administrators and for Group

choose jira-system-administrators. Click Add.

c. To verify your change, log out as admin and log in as the new JIRA
System Administrator, Mitch Davis (mdavis/Charlie!).
d. Click Continue, Next, Skip quick tour, and Skip to sign in as a new
user.
There's one more thing you need configure to give this JIRA
System Administrator full access to the instance (as requested by
Teams In Space). What is it?
Answer: Note the message that appears and recall from Module
3 that being an administrator means you have access to the
administration pages. But to be able to view or work in projects
you need to be in a group that has the appropriate application
access. We've created the jira-system-administrators group but
they don't have access to any JIRA applications.
e. Click Manage your application access in the message or close the

message and navigate to the Application access administration page
(under Applications).
f. Add the jira-system-administrators group to each of the three JIRA
applications:
i. Type jira-system-administrators in the field beneath JIRA
Service Desk and select the group when it appears. (Note that
there's no auto-fill of group name – we'll cover that later in this
lab.)
Even though some organizations may wish the JIRA System

Administrators and JIRA administrators to not have access to
applications, they can always add access themselves! So it would
be an honors system.

ii. Repeat this step for JIRA Software and JIRA Core.
Now JIRA System Administrators have access to all the features

and functions of each JIRA application as well as full
administrator access.
g. To confirm Mitch's JIRA System Administrators permission, navigate to

the Outgoing Mail administration page (under System). As a JIRA
System Administrator, Mitch can edit the SMTP Server settings. This is
something JIRA administrators cannot do.

3. Configure global permissions for JIRA administrators:
Dakota Jones has been identified as the JIRA administrator so Mitch can
now set her up.
a. Continuing as Mitch Davis (mdavis/Charlie!), the new System

Administrator, navigate to the Groups administration page (under User
Management).
b. Add Dakota Jones to the jira-administrators group:
i. In the jira-administrators' row, click Edit members.
ii. Click the User Picker icon under Add members to selected
group(s).
Were you able to do this? If not, why not?
Hover your mouse over the lock icon.
Answer: We gave the jira-system-administrators group the JIRA

System Administrators permission but we did not give the group
any other global permissions. So Mitch doesn't have the
permission to browse users.
iii. Log out as Mitch and log back in as the default System
iv. Navigate to the Global Permissions administration page (under
System) and use the Add Permission UI to add the following
global permissions to the jira-system-administrators group:
• Browse Users
• Create Shared Objects
• Manage Group Filter Subscriptions
• Bulk Change
v. Scroll up and confirm the jira-system-administrators group now

has all the global permissions.

c. Now we can continue on the task to add Dakota Jones to the JIRA
administrators group. Log out as admin and log back in as Mitch Davis
(mdavis/Charlie!) and return to the Groups administration page (under
User management).
i. In the jira-administrators' row, click Edit members.
ii. Now Mitch should be able to see the User Picker icon. Click the
User Picker icon.
iii. Select djones and click Select.
iv. Click Add selected users. You now see the admin user and
djones as group members of the jira-administrators group.
There's one more task Mitch needs to do to ensure Dakota has the
right permissions as a JIRA administrator (and not a JIRA System
Administrator). Do you know that that is?
Answer: Mitch needs to remove the JIRA System Administrators

permission from the jira-administrators group.
d. Navigate to the Global Permissions administration page (under System).

e. In the JIRA System Administrators row, click Delete under the jira-
administrators group to remove this permission from this group.
f. On the Delete Global Permissions screen, click Delete.

g. Back on the Global Permissions page confirm you now only have the
JIRA System Administrators permission for the jira-system-
administrators group the JIRA Administrators permission for the jira-
5. Verify Dakota's JIRA Administrators permission:

a. Log out and log back in as Dakota Jones (djones/Charlie!).
b. Click Continue, Next, Skip quick tour, and Skip to sign in as a new
user.
c. Navigate to the Outgoing Mail administration page (under System).
Can she see view and configure the SMTP Server?
Answer: No, she can only disable outgoing mail, which is all she
should be able to do as a JIRA administrator.

Exercise 2 – Removing the Bulk Change Permission
the next page.
1. Remove the Bulk Change permission from some default groups:

a. Continuing as the JIRA administrator, Dakota Jones (djones/Charlie!),
navigate to the Global permissions administration page.
What does the Bulk Change permission allow users to do?
Answer: This permission allows users to modify a collection of issues at

once. For example resolve multiple issues in one step. (There are also
permissions that relate to projects that control such things as who can
delete issues. We'll cover those in a later lab.)
Which groups have the Bulk Change permission?
Answer: jira-software-users, jira-servicedesk-users, jira-core-users,

jira-system-administrators, and jira-administrators.
Teams In Space has decided that only JIRA administrators and project
administrators should have the ability to modify a collection of issues in
one step. As we create project administrators we can assign them this
permission. Since we don't have any projects or project administrators
yet, let's restrict the permission to JIRA System Administrators and
JIRA administrators. (We'll be covering Project Administration later in
the course.)
b. Remove the Bulk Change global permission from the three default
groups: jira-core-users, jira-software-users, and jira-servicedesk-
users.

1. Remove the Bulk Change permission from some default groups:

a. Continuing as the JIRA administrator, Dakota Jones (djones/Charlie!),
navigate to the Global permissions administration page (under System).
What does the Bulk Change permission allow users to do?
Answer: This permission allows users to modify a collection of issues at

once. For example resolve multiple issues in one step. (There are also
permissions that relate to projects that control such things as who can
delete issues. We'll cover those in a later lab.)
Which groups have the Bulk Change permission?
Answer: jira-software-users, jira-servicedesk-users, jira-core-users,

jira-system-administrators, and jira-administrators.
Teams In Space has decided that only JIRA administrators and project
administrators should have the ability to modify a collection of issues in
one step. As we create project administrators we can assign them this
permission. Since we don't have any projects or project administrators
yet, let's restrict the permission to JIRA System Administrators and
JIRA administrators. (We'll be covering Project Administration later in
the course.)
b. In the Bulk Change row, delete the three default groups: jira-core-
users, jira-software-users, and jira-servicedesk-users. You will need
to click Delete again to confirm for each of them.

Optional Exercise 3 – Exploring Non-Administrator Permissions
the next page.
1. Observe the Browse Users permission:

a. On the Global Permissions page, read the description of the Browse
Users permission.
b. To see it in action, log out and log in as Ryan Lee (rlee/Charlie!).
c. Even though we don't have any issues yet, we'll use the Issue Navigator
just to see how Ryan can browse users. Click his user profile dropdown
and select Issue Navigator. This will make the Issue Navigator his home
page and will also allow us to observe this permission.
d. Share the filter and start typing the letters ca. Two users should appear
in the drop-down: Cassie Owens and Kevin Campbell. Only users with
the Browse Users permission can interact with these sorts of User Picker
fields, which are available throughout JIRA.
3. Observe the Create Shared Objects permission:

The Create Shared Objects permission gives users the ability to share
dashboards and filters with other users, groups and roles.
a. Continuing as Ryan Lee, click Dashboards – Manage Dashboards and
create a new dashboard.
Note the message 'Sharing with everyone will make this public and
visible to users who are not logged in.' If we leave the default share to
everyone that means even non-logged in users will be able to see the
dashboard.
b. Create the new dashboard:

i. Name: Development Status
ii. Start From: Select Blank dashboard
iii. Add Shares: Select the Development group, and then click
+Add.
Now you should see Group: Development next to Shares. Only
users with the Create Shared Objects can create and share
dashboards.
iv. Add the new dashboard and now you see the new dashboard
listed in Ryan's Favorite Dashboards. Note that the group
Development is listed under Shared With.
c. Test shared access to the dashboard.

i. Log out as Ryan and log in as a user in the Development group,
Max Taylor (mtaylor/Charlie!).
ii. Navigate to Manage Dashboards.
iii. Search for Development.

iv. The Development Status dashboard should appear in Search.
Make it a Favorite.
v. View Max's favorites and you should see the dashboard.
vi. Let's ensure users in other groups cannot see the dashboard.
Log out as Max and log in as a member of the Human Resources
group, Luis Beck (lbeck/Charlie!).
vii. Search again for Development in Manage Dashboards.
Nothing is returned as Ryan only shared his dashboard with the
Development group.
1. Observe the Browse Users permission:
a. On the Global Permissions page, read the description of the Browse
Users permission.
b. To see it in action, log out and log in as Ryan Lee (rlee/Charlie!).

c. Even though we don't have any issues yet, we'll use the Issue Navigator
just to see how Ryan can browse users. Click his user profile dropdown
and select Issue Navigator. This will make the Issue Navigator his home
page and will also allow us to observe this permission.

d. Click Share at the top of the page and start typing the letters ca.
Two users should appear in the drop-down: Cassie Owens and Kevin
Campbell. Only users with the Browse Users permission can interact
with these sorts of User Picker fields, which are available throughout
JIRA.
e. Click Cancel.
2. Observe the Create Shared Objects permission:

The Create Shared Objects permission gives users the ability to share
dashboards and filters with other users, groups and roles.
a. Continuing as Ryan Lee, click Dashboards – Manage Dashboards.
b. Click Create new dashboard.
Note the message 'Sharing with everyone will make this public and
visible to users who are not logged in.' If we leave the default share to
everyone that means even non-logged in users will be able to see the
dashboard.
c. Create the new dashboard:

i. Name: Development Status
ii. Optionally enter a description
iii. Start From: Blank dashboard
iv. Add Shares: Select Group then Development group, and then
click +Add.
Now you should see Group: Development next to Shares. Only
users with the Create Shared Objects can create and share
dashboards.
v. Click Add at the bottom of the page.

Now you see the new dashboard listed in Ryan's Favorite
Dashboards. Note that the group Development is listed under
Shared With.
d. Test shared access to the dashboard.

i. Log out as Ryan and log in as a user in the Development group,
Max Taylor (mtaylor/Charlie!).
ii. Click Continue, Next, and Skip quick tour to sign in as a new
user.
iii. Click Dashboards – Manage Dashboards.
iv. Click Search on the left.

v. Enter Development in the Search box and click Search.
vi. The Development Status dashboard should appear in Search.

Click the star next to the dashboard to make it a Favorite.
vii. Click Favorites on the left and you should now see it as one of
Max's favorites.
viii. Let's ensure users in other groups cannot see the dashboard.
Log out as Max and log in as a member of the Human Resources
group, Luis Beck (lbeck/Charlie!).
ix. Click Dashboards – Manage Dashboards.
x. Click Search on the left.
xi. Enter Development in the Search box and click Search.
Nothing is returned as Ryan only shared his dashboard with the

Development group.

Optional Exercise 4 –Exploring the JIRA Administrator
Differences
the next page.
1. Review the difference between JIRA System Administrators and JIRA

administrators at this URL in the section About JIRA System Administrators and
JIRA Administrators http://go.atlassian.com/global_perms.
Consider the purpose of differentiating these two types of permissions.

How might you take advantage of this at your own organization?
The default configuration in JIRA is that one group, jira-administrators,

has both JIRA System Administrators and JIRA Administrators
permissions. When would it make sense to split the permissions into two
separate groups?
Answer: When you choose to separate administrators into different

categories of privileges (JIRA administrators and JIRA System
Administrators), you are saying that some of your administrators should
not be allowed to make certain system-wide configurations. This is useful
if the expertise to make those changes resides in a small number of
people. The downside to limiting the administrator privileges for JIRA
administrators is that they sometimes need assistance to configure JIRA.
Balance limiting privileges with how responsive system administrators

can be to requests for assistance.
2. View various administration pages to see the difference between JIRA

administrators and JIRA System Administrators:
a. Log in as the JIRA administrator, Dakota Jones, (djones/Charlie!) and
navigate to the Global Permissions administration page.
How is this screen different for a JIRA administrator than it was

when you were logged in as a JIRA System Administrator?
Answer: You cannot view or change the JIRA System

Administrator permissions if you are logged in as a JIRA
administrator.
b. Scroll through the System sidebar to the left. Many options that are
available to the System Administrator are missing, for example, Database
monitoring, Logging and profiling, etc. Other options are available as
links, but trigger login requests when clicked.

c. Navigate Support Tools under TROUBLESHOOTING AND SUPPORT in
the left sidebar.
Dakota doesn't have permission to access the Support Tools page as

this is limited to JIRA System Administrators. You are presented with a
login page so you could log in as a System Administrator.
Click the browser back arrow.
1. Review the difference between JIRA System Administrators and JIRA

administrators at this URL in the section About JIRA System Administrators and
JIRA Administrators http://go.atlassian.com/global_perms.
Consider the purpose of differentiating these two types of permissions.

How might you take advantage of this at your own organization?
The default configuration in JIRA is that one group, jira-administrators,

has both JIRA System Administrators and JIRA Administrators
permissions. When would it make sense to split the permissions into two
separate groups?
Answer: When you choose to separate administrators into different

categories of privileges (JIRA administrators and JIRA System
Administrators), you are saying that some of your administrators should
not be allowed to make certain system-wide configurations. This is useful
if the expertise to make those changes resides in a small number of
people. The downside to limiting the administrator privileges for JIRA
administrators is that they sometimes need assistance to configure JIRA.
Balance limiting privileges with how responsive system administrators

can be to requests for assistance.
2. View various administration pages to see the difference between JIRA

administrators and JIRA System Administrators:
a. Log in as the JIRA administrator, Dakota Jones, (djones/Charlie!).
b. Navigate to the Global Permissions administration page (under System).
How is this screen different for a JIRA administrator than it was

when you were logged in as a JIRA System Administrator?
Answer: You cannot view or change the JIRA System

Administrator permissions if you are logged in as a JIRA

administrator.
c. Scroll through the System sidebar to the left. Many options that are
available to the System Administrator are missing, for example, Database
monitoring, Logging and profiling, etc. Other options are available as
links, but trigger login requests when clicked. For reference, on the left is
what Dakota sees at the top of the System sidebar. On the right is what
Mitch, the JIRA System Administrator, sees at the top of the System
sidebar.
d. Click Support Tools under TROUBLESHOOTING AND SUPPORT in the

left sidebar.

Dakota doesn't have permission to access the Support Tools page as
this is limited to JIRA System Administrators. You are presented with a
login page so you could log in as a System Administrator. Click the
browser back arrow.

Lab 4 Appendix
Further reading
Reference URL
Managing http://go.atlassian.com/global_perms
global
permissions
Best Practices
Unavailable JIRA Company X has two JIRA System Balance limiting privileges
System Administrators and two JIRA with how responsive JIRA
Administrators administrators. The JIRA System Administrators are
could create administrators became aware of a to requests for assistance.
difficulties for JIRA change needed to JIRA that
administrators. requires system administrator
privileges but they cannot get
hold of either of the System
Administrators to make the
change.
No one to do Your JIRA system has a problem In a production system,

system that needs to be addressed by the have at least two JIRA
administration JIRA System Administrator but System Administrators
tasks when the she just left for a week long (and JIRA administrators)
one system vacation and no one else has the set up in JIRA even if one
administrator is System Administrator permission! person performs the role.
unavailable.
Unknown public The Anyone group was assigned You should avoid using
users can perform the Browse Users permission by Anyone with Global
operations only mistake. A malicious person was Permissions, especially for
JIRA non-public able to find out all the names of public or production
users should be internal users at the company instances. The Anyone
able to perform. without even logging in. group grants the
permission you've chosen
to non logged-in users

Lab 5 – Creating & Configuring Projects
Scenario
You now need to create a JIRA project for the Teams In Space Human Resources
project team. This is where they'll create issues and do their work. You also have
received requests from the Human Resources project lead to update the workflow to
reflect their business requirement, change fields on a screen to make it easier for their
team members, and create a new issue type to represent job applicants.
Here you log in as the JIRA administrator Dakota Jones and perform the following
tasks:
• Create a Business (Core) project
• View the default issue types and workflow for the project
• Edit project details
• Update the project workflow
• Make a backup of the original project workflow
• Edit a screen
• Add an issue type to a project
• Change the workflow for an issue type
• Optional:
o Update a workflow
o View your activity
Exercise 1 – Creating a Project

Page 92.
1. Log in to JIRA as the JIRA administrator Dakota Jones (djones/Charlie!).

2. Navigate to the Issue types administration page and view the default issue
types.
Why do you only see two issue types?
Answer: Because JIRA Software was the first application installed and
these are the default ones created. As you create projects, you will see
the default issue types for those projects added.
3. Create a Business (Core) project:

a. From the Projects menu, create a project.
b. Teams In Space wants a fairly simple Business project to manage its
Human Resources tasks. Choose the Project management template
and continue.
c. View the default issue types and workflow for this project template.
What issue types does this type of project have?

Answer: Task and Sub-task issue types.
What statuses could an issue of these types be in?
Answer: TO DO, IN PROGRESS, or DONE.
d. Continue and name the project Human Resources and leave the key at
HR.
The key is used as the prefix of this project's issue keys. For example,
your first issue's key will be HR-1. If there are multiple words in the
project name, the key will be filled in with the first letter of each of the
words in the name.
You can change the default project key here but if you do, choose a key
that is descriptive and easy to type. Users will often use the issue key to
find an issue and you want to make it as easy as possible for them so
don't use overly long keys. The key can be changed after project
creation but it is not a trivial task so choose carefully here.
e. Sophie Nguyen has been identified as the project lead so select her and
create the project.
The project lead is the person who manages the project within and
outside JIRA. This person is often used as the default assignee for
triaging new issues. We'll discuss project roles in more detail in the next
module.
f. You are taken to the Open Issues filter page. We won't create any issues
yet.
4. Edit project details:

a. Click Project administration in the bottom of the project sidebar to
access the project's administration pages. If you minimize the project
sidebar, you can just click the cog icon to get to project administration.
JIRA has two types of administration pages – the JIRA administration

pages and the project administration pages. The JIRA administration
pages cover the whole JIRA instance. These you access from the
Administration cog icon in the top menu or by typing '.' (period) then the
name of the page. The project administration pages only apply to the
project itself and are accessed from within the project by clicking the
Administration cog icon in the project sidebar.
b. Edit the project details and change the Project Avatar (icon). Choose any
of the supplied icon.

It's good to have an avatar that is representative of your project. If none
of the supplied avatars suit your purposes you can upload your own.
c. Optionally enter a Description: Human Resources tasks to manage

Teams In Space employees across the universe.
The Description is optional, but is useful, especially if you have many

projects.
d. Finish updating and you should now see the new project avatar.
5. Navigate back to the Issue types administration page (under Issues in JIRA
Administration not Project Administration). Now you see two new issue types –
Task and Sub-task that are used by the HR: Project Management Issue Type
scheme for the new project.
When you create a new project a set of schemes will automatically be

created just for the new project.
1. Log in to JIRA as the JIRA administrator Dakota Jones (djones/Charlie!).
2. View default issue types:
a. Navigate to the Issue types administration page (under Issues).
Why do you only see two issue types?
Answer: Because JIRA Software was the first application installed and
these are the default ones created. As you create projects, you will see
the default issue types for those projects added.

3. Create a Business (Core) project:
a. From the menu click Projects > Create Project.
b. Teams In Space wants a fairly simple Business project to manage its

Human Resources tasks. Under Business, select Project management
and click Next.

c. View the default issue types and workflow for this project template.
What issue types does this type of project have?
Answer: Task and Sub-task issue types.
What statuses could an issue of these types be in?
Answer: TO DO, IN PROGRESS, or DONE.
d. Click Select.
e. Name the project Human Resources and leave the key at HR.
The key is used as the prefix of this project's issue keys. For example,
your first issue's key will be HR-1. If there are multiple words in the
project name, the key will be filled in with the first letter of each of the
words in the name.
You can change the default project key here but if you do, choose a key
that is descriptive and easy to type. Users will often use the issue key to
find an issue and you want to make it as easy as possible for them so
don't use overly long keys. The key can be changed after project
creation but it is not a trivial task so choose carefully here.
f. Sophie Nguyen has been identified as the project lead. Start typing
sophie and select Sophie Nguyen. Click Submit.

The project lead is the person who manages the project within and
outside JIRA. This person is often used as the default assignee for
triaging new issues. We'll discuss project roles in more detail in the next
module.
g. You are taken to the Open Issues filter page. We won't create any issues
yet.
4. Edit project details:

a. Click Project administration in the bottom of the project sidebar on the
left to access the project's administration pages. If you minimize the
project sidebar, you can just click the cog icon to get to project
administration.
JIRA has two types of administration pages – the JIRA administration

pages and the project administration pages. The JIRA administration
pages cover the whole JIRA instance. These you access from the
Administration cog icon in the top menu or by typing '.' (period) then the
name of the page. The project administration pages only apply to the
project itself and are accessed from within the project by clicking the
Administration cog icon in the project sidebar.
b. Click Edit Project on the top right to edit the project details.
c. To change the Project Avatar (icon), click the current avatar or select
image next to it.

d. In the project avatar dialog, click any icon.
It's good to have an avatar that is representative of your project. If none

of the supplied avatars suit your purposes you can upload your own
image.
e. Optionally enter a Description: Human Resources tasks to manage

Teams In Space employees across the universe.

The Description is optional, but is useful, especially if you have many
projects.
f. Click Update and you should now see the new project avatar.
5. Navigate back to the Issue types administration page (under Issues in JIRA
Administration not Project Administration). Now you see two new issue types –
Task and Sub-task that are used by the HR: Project Management Issue Type
scheme for the new project.

When you create a new project a set of schemes will automatically be
created just for the new project.
Exercise 2 – Updating the Workflow for a Project

Page 102.
1. Continuing as the JIRA administrator Dakota Jones (djones/Charlie!), view the

default workflow for the HR project:
a. Return to your new project by clicking Back to project: Human
Resources.
b. Navigate to the Workflows project administration page and view the
project workflow in diagram mode.
c. Here you see a diagrammatic representation of the default workflow for
this project. Mouse over the statuses to see the transition names.
What transitions come into and out of the DONE status? And where do
they come from or go to?
Answer: A Done transition goes from both IN PROGRESS and TO DO to

DONE. A Reopen transition goes from DONE to TO DO, a Reopen and
start progress goes from DONE to IN PROGRESS.
d. View the workflow in text mode, which shows a series of steps.
This view gives you a bit more information, for example, what screens
will appear for some transitions.

e. Exit the workflow.
2. Edit the workflow for the HR project:
The default workflows for project templates are provided to you as a starting
point. In many cases they may be sufficient but often you will need to modify
them to suit your business needs.
The Human Resources project lead, Sophie, wants to see which issues have
been reopened. To do that, you can create a REOPENED status and then she
can create a filter searching for HR issues with that status.
a. Edit the HR: Project Management Workflow.
b. Now you are taken to the Workflows edit page for this particular
workflow in JIRA Administration. Check Show transition labels to make
it easier to see the transitions.
Note the DRAFT lozenge next to the name. You cannot edit a live
workflow that is in use in a project. When you edit a workflow you are
always editing a draft version of that workflow.
It's often easier to build workflows in Diagram mode as it's presented in

a visual way. This mode also has a workflow validator, which visually
highlights potential errors. This is good when working with complex
workflows. However when you're editing transitions, you may want to
use Text mode. This allows you to see the unique id, which is useful if
you have multiple transitions with the same name.
Once an issue is Done, if it's reopened the project lead wants it to go to

a REOPENED status. After it's been reviewed, it will be sent back to the
queue i.e. to the TO DO status. Currently there are two outgoing
transitions from DONE – Reopen and Reopen and start progress. So you
need to first delete both those outgoing transitions. Then add a new
status, REOPENED. Then add a transition, Reopen, from DONE to
REOPENED. Then add a transition, Back to Queue, from REOPENED to
TO DO. (Instructions are given below.)
c. Delete the existing Reopen transition from DONE to TO DO.

d. Delete the Reopen and start progress transition from DONE to IN
PROGRESS.
e. Add the new Reopened status.
f. Add a Reopen transition from DONE to REOPENED:
i. From status: Done
ii. To status: Reopened
iii. Name: Reopen
iv. Optional Description: The issue was resolved but now it has
been reopened
v. Screen: None

When would you want to add a screen to a transition?
Answer: When you need the person who is reopening the issue
to enter some information. A possible reason you might want to
add a screen here is when you want the person reopening the
issue to add a reason why this issue is being reopened. For now
we'll keep things simple and leave it at no screen.
g. The new incoming transition is created. Drag the REOPENED status to

the left of the screen to make the diagram clearer.
h. By clicking on the status, you open the Reopened dialog. Add a Back to
Queue transition from REOPENED to TO DO.
i. From status: Reopened
ii. To status: To Do
iii. Name: Back to Queue
iv. Optional Description: The reopened issue goes back to the
queue of open issues
v. Screen: None
i. Your workflow should now look like this with the new status and
transitions in place:
You can grab anywhere in the white space and drag the whole diagram
around to give you more space on one side or center it.
3. Publish the draft workflow and save the original workflow:

a. When you are satisfied with your edits, publish the draft. Save a backup
copy and rename the Backup workflow name to Original HR: Project
Management Workflow.
b. Once you publish, you should see a message that your workflow is
active.
You cannot edit a live workflow that is in use in a project. When you edit
a workflow you are always editing a draft version of that workflow. Before
your edits can be used, you must publish that Draft. In contrast, if you
were to work on a workflow that was not already in use (an inactive
workflow), edits would be saved immediately, without the intermediate
Draft stage. So whenever you update a workflow that is currently in use,
you must make certain that you have published your changes.
It's always a good idea to save a backup copy of a workflow when you
edit. That way you can always go back to the original if you make
mistakes.
4. Test new workflow:

Now let's create a test issue and walk it through your workflow to confirm your
changes have been applied successfully. It's always a good idea to test
immediately after editing a workflow.
a. Create a test issue and view the workflow.
b. Confirm the new Reopened status plus its transitions are there then
close the Workflow window.
c. The part of your workflow that's new is the REOPENED status and its
transitions. So, let's walk through the following steps: Open -> In
Progress -> Done -> Reopened. (Steps below.)
d. Start Progress on the issue to start moving it through the workflow.
What is the status of the issue now?
Answer: The status has changed to IN PROGRESS.
e. Click Done and for Resolution select Done then click Done. This is an
example of a screen attached to a transition.
What is the status now?
Answer: The status should be DONE.
f. You should now see your new transition, Reopen. Reopen the issue.
g. Now the status should be REOPENED. Send the issue back to the
queue.
At Teams In Space this issue may stay in the REOPENED status until
someone has reviewed it. To keep it simple here we're transitioning it
back to the queue immediately.
h. Now the status has changed back to TO DO and Start Progress and
Done are your options for transitions.
Does anything else need to be done to this workflow?
Answer: Resolution now shows Done when it should show something

like Reopened or Unresolved. You can handle that in two ways – create a
new screen that allows you to enter various Resolutions and attach it to

one of your transitions. Or you could have the workflow automatically
change resolution once you click Reopen. This is done by Post functions,
which are covered in the JIRA Administration Part 2 course and the
Getting More from JIRA Workflows course.
5. View workflow administration:

a. Navigate to Workflows JIRA Administration page. Here you see the HR:
Project Management Workflow that you edited.
b. Look at the inactive workflows. Here is where you see the Original HR:
Project Management Workflow that you saved earlier. Later in this lab
we'll see how you can use this inactive workflow for a new issue type.
6. Troubleshoot workflow:
What if something didn't work out correctly in the test you just did? If you were
missing transition options or if the resulting statuses weren't correct, that means
you need to go back to your workflow and check that you've configured
everything correctly. For anything that didn't go as expected - make a note of
the status from which you were starting when the problem manifested. For
example:
a. If you were in the Done status and did not see a Reopen button, then you
need to edit the workflow and add or edit the Done status Reopen
transition.
b. Or maybe you were in the Done status and saw two buttons – Reopen
and Reopen and start progress. In this case you need to edit the
workflow and remove the Reopen and start progress transition between
the Done and In Progress statuses.
1. Continuing as the JIRA administrator Dakota Jones (djones/Charlie!), view the
default workflow for the HR project:
a. Return to your new project by clicking Back to project: Human
Resources on the top right of the page.
b. Click Workflows in the project sidebar.

c. Click diagram to view the project workflow in diagram mode.
d. Here you see a diagrammatic representation of the default workflow for

this project. Mouse over the statuses to see the transition names.
What transitions come into and out of the DONE status? And where do
they come from or go to?
Answer: A Done transition goes from both IN PROGRESS and TO DO to

DONE. A Reopen transition goes from DONE to TO DO, a Reopen and
start progress goes from DONE to IN PROGRESS.

e. Click Close then click Text to view in text mode as a series of steps.
This view gives you a bit more information, for example, what screens
will appear for some transitions.
f. Close the Text dialog.
2. Edit the workflow for the HR project:
The default workflows for project templates are provided to you as a starting
point. In many cases they may be sufficient but often you will need to modify
them to suit your business needs.
The Human Resources project lead, Sophie, wants to see which issues have
been reopened. To do that, you can create a REOPENED status and then she
can create a filter searching for HR issues with that status.
a. Click the Edit icon for workflow (under Operations). If prompted, re-enter
your Administrator password (Charlie!).
b. Now you are taken to the Workflows edit page for this particular
workflow in JIRA Administration. Check Show transition labels to make
it easier to see the transitions.

Note the DRAFT lozenge next to the name. You cannot edit a live
workflow that is in use in a project. When you edit a workflow you are
always editing a draft version of that workflow.
It's often easier to build workflows in Diagram mode as it's presented in

a visual way. This mode also has a workflow validator, which visually
highlights potential errors. This is good when working with complex
workflows. However when you're editing transitions, you may want to
use Text mode. This allows you to see the unique id, which is useful if
you have multiple transitions with the same name.
Once an issue is Done, if it's reopened the project lead wants it to go to

a REOPENED status. After it's been reviewed, it will be sent back to the
queue i.e. to the TO DO status. Currently there are two outgoing
transitions from DONE – Reopen and Reopen and start progress. So you
need to first delete both those outgoing transitions. Then add a new
status, REOPENED. Then add a transition, Reopen, from DONE to
REOPENED. Then add a transition, Back to Queue, from REOPENED to
TO DO. (Detailed instructions are given below.) Here's what it should
look like when you're done:

c. Delete the existing Reopen transition from DONE to TO DO by clicking
the Reopen label on the diagram. A dialog pops up for the Reopen
transition. Ensure it's the Reopen transition and not the Done transition!
Click Delete transition and then Delete to confirm.
d. Repeat this step to delete the Reopen and start progress transition
from DONE to IN PROGRESS. Your workflow should now look like this:

e. Now let's add the new Reopened status. Click Add status and from the
drop down list select Reopened. Click Add.
f. You now see your new status on the diagram and it's selected. Next you
need to add the transitions – click Add Transition in the Reopened
dialog.

g. Add a Reopen transition from DONE to REOPENED.
i. From status: Done
ii. To status: Reopened
iii. Name: Reopen
iv. Optional Description: The issue was resolved but now it has
been reopened
v. Screen: None
vi. Click Add
When would you want to add a screen to a transition?

Answer: When you need the person who is reopening the issue
to enter some information. A possible reason you might want to
add a screen here is when you want the person reopening the
issue to add a reason why this issue is being reopened. For now
we'll keep things simple and leave it at no screen.
h. The new incoming transition is created. Drag the REOPENED status to

the left of the screen to make the diagram clearer.
i. By clicking on the status, you opened the Reopened dialog. Click Add
Transition in the dialog and add a Back to Queue transition from
REOPENED to TO DO.
i. From status: Reopened
ii. To status: To Do
iii. Name: Back to Queue
iv. Optional Description: The reopened issue goes back to the
queue of open issues
v. Screen: None

vi. Click Add
j. Your workflow should now look like this with the new status and
transitions in place:
You can grab anywhere in the white space and drag the whole diagram
around to give you more space on one side or center it.
3. Publish the draft workflow and save the original workflow:

a. When you are satisfied with your edits, click Publish Draft.

You cannot edit a live workflow that is in use in a project. When you edit
a workflow you are always editing a draft version of that workflow. Before
your edits can be used, you must publish that Draft. In contrast, if you
were to work on a workflow that was not already in use (an inactive
workflow), edits would be saved immediately, without the intermediate
Draft stage. So whenever you update a workflow that is currently in use,
you must make certain that you have published your changes.
b. Select Yes for Save a backup copy and rename the Backup workflow
name to Original HR: Project Management Workflow. Click Publish.
You should see a message that your workflow is active.
It's always a good idea to save a backup copy of a workflow when you
edit. That way you can always go back to the original if you make
mistakes.
4. Test new workflow:

Now let's create a test issue and walk it through your workflow to confirm your
changes have been applied successfully. Always test immediately after editing a
workflow.

a. Create a test issue.
i. On the top menu click Create.
ii. Summary: Test 1.

iii. Optional Description: Walk through the workflow with this
issue.
iv. Scroll down and click Create.
b. View the workflow from the issue by clicking View Workflow.
c. Confirm the new Reopened status plus its transitions are there then
close the Workflow window.
d. The part of your workflow that's new is the REOPENED status and its
transitions. So, let's walk through the following steps: Open -> In
Progress -> Done -> Reopened. (Detailed steps below.)

e. Click Start Progress to start moving this issue through the workflow.
What is the status of the issue now?
Answer: The status has changed to IN PROGRESS.
f. Click Done.
g. On the Done screen, for Resolution select Done then click Done. This is
an example of a screen attached to a transition.

What is the status now?
Answer: The status should be DONE.
h. You should now see your new transition, Reopen. Click Reopen.
i. Now the status should be REOPENED. Click Back to Queue.
At Teams In Space this issue may stay in the REOPENED status until
someone has reviewed it. To keep it simple here we're transitioning it
back to the queue immediately.
j. Now the status has changed back to TO DO and Start Progress and
Done are your options for transitions.
Does anything else need to be done to this workflow?
Answer: Resolution now shows Done when it should show something

like Reopened or Unresolved. You can handle that in two ways – create a
new screen that allows you to enter various Resolutions and attach it to
one of your transitions. Or you could have the workflow automatically
change resolution once you click Reopen. This is done by Post functions,
which are covered in the JIRA Administration Part 2 course and the
Getting More from JIRA Workflows course.

5. View workflow administration:
a. Navigate to Workflows JIRA Administration page. Here you see the HR:
Project Management Workflow that you edited.
b. Expand Inactive under your workflow. Here is where you see the Original
HR: Project Management Workflow that you saved earlier. Later in this
lab we'll see how you can use this inactive workflow for a new issue
type.
6. Troubleshoot workflow:
What if something didn't work out correctly in the test you just did? If you were
missing transition options or if the resulting statuses weren't correct, that means
you need to go back to your workflow and check that you've configured
everything correctly. For anything that didn't go as expected - make a note of
the status from which you were starting when the problem manifested. For
example:
a. If you were in the Done status and did not see a Reopen button, then you
need to edit the workflow and add or edit the Done status Reopen
transition.
b. Or maybe you were in the Done status and saw two buttons – Reopen
and Reopen and start progress. In this case you need to edit the
workflow and remove the Reopen and start progress transition between
the Done and In Progress statuses.

Exercise 3 – Updating Fields & Screens in a Project
Page 118.
1. View fields:
a. Continuing as the JIRA administrator Dakota Jones (djones/Charlie!),
navigate back to the Human Resources project administration pages and
view the Fields project administration page.
Field configurations define how fields behave, for example, whether they
are required or optional, hidden or visible, etc. This field configuration is
the system default field configuration (meaning it applies to the whole of
JIRA) and shows all the fields configured in JIRA, their properties and
where they are used.
If you edit this system default field configuration it will apply to all
projects!
It is possible to edit fields just for the Human Resources project. For
example, we may want the xyz field to be required in this project but not
in others. But to do so you need to create a new field configuration
scheme and then associate it with this project. You could do that by
copying the System Default Field Configuration and editing the copy.
We'll cover editing schemes later in the course.
b. For the Assignee field, view the five screens it's used on.
What screens is this field used on?
Answer: The Default, HR: Project Management Create Issue, HR: Project
Management Edit/View Issue, Resolve Issue, and Workflow screens.
c. Scroll down and view the Summary field.
Is Summary a required field?
Answer: Yes, it is required.
d. Leave the fields at their default configuration.
2. Edit a screen:
We're going to edit the Create Issue screen and remove a field that's not needed
for the Human Resources project. We'll also move a field to a new location on
the screen. But before we edit the screen, let's look at what the default Create
Issue screen looks like.

a. Start to create a new issue and view all the fields that make up the
Create Issue screen. Click Create before entering anything.
What happened?
Answer: You got an error that you must specify a summary of the issue
because this is a required field. Note the asterisk, which means it's
required.
Is that the only required field?
Answer: No, the Reporter field is also required. However, this is

automatically filled with the person who creates the issue.
b. Scroll down and notice the Labels field. The Human Resources project
lead has requested the JIRA administrator to remove this field, as it's not
used.
It's a good idea to remove unused fields to help simplify the screens for
users and make them easier to use.
c. Also note the location of the Priority field – down the screen beneath
Assignee. The project lead wants it higher on the screen to make it more
noticeable.
d. Enter some test data and create the issue.
e. Navigate to the Screens Human Resources project administration page.
This shows you the Issue Type Screen Scheme for this project. It lists the
screens used for the two issue types, Task and Sub-task, in this project.
f. Open HR: Project Management Create Issue Screen. These are the
fields and the way they're organized on the Create Issue screen for the
Human Resources project.
g. Remove the Labels field as the Human Resources project lead says it's
not used.
h. Also move the Priority field up above Description as the project lead
wants to make it more noticeable.
i. Test your screen changes by creating a new issue. The Labels field
should no longer be there and the Priority field should be above
Description.

1. View fields:
navigate back to the Human Resources project administration pages and
view the Fields project administration page.
Field configurations define how fields behave, for example, whether they
are required or optional, hidden or visible, etc. This field configuration is
the system default field configuration (meaning it applies to the whole of
JIRA) and shows all the fields configured in JIRA, their properties and
where they are used.
If you edit this system default field configuration it will apply to all
projects!
It is possible to edit fields just for the Human Resources project. For
example, we may want the xyz field to be required in this project but not
in others. But to do so you need to create a new field configuration
scheme and then associate it with this project. You could do that by
copying the System Default Field Configuration and editing the copy.
We'll cover editing schemes later in the course.
b. For the Assignee field, click the 5 screens link.
What screens is this field used on?

Answer: The Default, HR: Project Management Create Issue, HR: Project
Management Edit/View Issue, Resolve Issue, and Workflow screens.
c. Scroll down and view the Summary field.
Is Summary a required field?
Answer: Yes, it is required.
d. Leave the fields at their default configuration.
2. Edit a screen:
We're going to edit the Create Issue screen and remove a field that's not needed
for the Human Resources project. We'll also move a field to a new location on
the screen. But before we edit the screen, let's look at what the default Create
Issue screen looks like.
a. In the top menu, click Create to create a new issue.
i. View all the fields that make up the Create Issue screen.
Scroll down and click Create before entering anything.
What happened?
Answer: You got an error that you must specify a summary of the
issue because this is a required field. Note the asterisk, which
means it's required.
ii. For Summary, enter Test 2.
Is that the only required field?
Answer: No, the Reporter field is also required. However, this is

automatically filled with the person who creates the issue.
iii. Optionally for Description, enter Test issue.

iv. Scroll down and notice the Labels field. The Human Resources
project lead has requested the JIRA administrator to remove this

field, as it's not used.
It's a good idea to remove unused fields to help simplify the

screens for users and make them easier to use.
v. Also note the location of the Priority field – down the screen
beneath Assignee. The project lead wants it higher on the screen
to make it more noticeable.
vi. Scroll down and click Create.

b. Navigate to the Screens Human Resources project administration page.
Click the Human Resources link above the name of the issue next
to the avatar. Then click Project administration.
This shows you the Issue Type Screen Scheme for this project. It lists the
screens used for the two issue types, Task and Sub-task, in this project.

c. Click on one of the screens, HR: Project Management Create Issue
Screen.
d. These are the fields and the way they're organized on the Create Issue
screen for the Human Resources project.
e. The Human Resources project lead wants to remove the Labels field, as
it's not used. Hover over the Labels row and click Remove.
f. Also the project lead wants to move the Priority field up above
Description so it's more noticeable. Grab the dotted area to the left of
Priority and drag it up to be above the Description field.

g. Test your screen changes by creating a new issue.
i. In the top menu, click Create
The Labels field should no longer be there and the Priority field
should be above Description.
ii. For Summary enter Test 3 then click Create.

Exercise 4 – Adding an Issue Type to a Project & Changing its
Workflow
the next page.
1. Add an Issue Type to a project:

navigate to the Issue Types Human Resources project administration
page. Here you see the two default issue types for this project – Task
and Sub-task. The Human Resources project lead has decided that they
will manage job candidates in this project. So she wants a new issue
type called Person. Each issue of this type will represent a job applicant.
b. Edit the issue types (under Actions). This takes you to the Modify Issue
Type Scheme page for the HR: Project Management Issue Type Scheme
in JIRA Administration.
c. Add an issue type:
i. Name: Person
ii. Optional Description: Applicant for a position with Teams In
Space
iii. Type: Standard Issue Type
d. Your new Person issue type is now listed in the current scheme for the
Human Resources project. Save.
e. Observe how this new Person issue type is associated with the:
i. HR: Project Management Workflow – any new issues created
using this issue type in the Human Resources project will follow
this workflow.
ii. Default Field Configuration – this issue type will be available for
other projects.
iii. HR: Project Management Screen Scheme – this issue type will
appear on Human Resources project screens.
f. Optionally, change the avatar (icon) for the issue type. The ideal avatar
for this issue type would be a person and you could browse and use your
own custom avatar at your organization. Here choose the heart avatar.
g. Test the new issue type:

i. Create a new issue using your new Person issue type.
You need to specify which project to create the issue in when you
create an issue from JIRA Administration.
ii. Notice it's the same create screen as Task issue type. Enter a
Summary and create the issue.
h. On the issue page, view the workflow to confirm it's the same workflow
as for a Task issue type (the one that you edited earlier).

2. Change the workflow for an issue type:
For this new Person issue type we'll need a new workflow. This will be different
from the Task workflow that we edited earlier so it's easier to start with the
original default workflow that came with this project template. Recall you saved
the original workflow earlier after you edited the workflow.
a. Navigate to the Workflows Human Resources administration page. You
see all three issue types are associated with the HR: Project
b. Add an existing workflow and select Original HR: Project Management
Workflow. Select the Person issue type and finish.
c. Confirm the Task and Sub-task issue types are using HR: Project
Management Workflow and Person issue type is using Original HR:
Project Management Workflow then publish.
d. Now it shows which status will be changed. In this case, REOPENED will
be change to To Do. Click Associate and once it's finished migrating
issues to the new workflow, acknowledge the migration.
e. Create another issue of type Person and view Workflow to verify it's now
using the original workflow.
1. Add an Issue Type to a project:
navigate to the Issue Types Human Resources project administration
page. Here you see the two default issue types for this project – Task
and Sub-task. The Human Resources project lead has decided that they
will manage job candidates in this project. So she wants a new issue
type called Person. Each issue of this type will represent a job applicant.
b. Click Actions – Edit issue types.
c. This takes you to the Modify Issue Type Scheme page for the HR:
Project Management Issue Type Scheme in JIRA Administration. Click
+ Add Issue Type.

d. On the Add Issue Type dialog enter:
i. Name: Person
ii. Optional Description: Applicant for a position with Teams In
Space
iii. Type: Standard Issue Type
iv. Click Add.
e. Your new Person issue type is now listed in the current scheme for the

f. Click Save.
g. Observe how this new Person issue type is associated with the:
i. HR: Project Management Workflow – any new issues created
using this issue type in the Human Resources project will follow
this workflow.
ii. Default Field Configuration – this issue type will be available for
other projects.
iii. HR: Project Management Screen Scheme – this issue type will
appear on Human Resources project screens.
h. Optionally, change the avatar (icon) for the issue type:
i. Navigate to the Issue types JIRA administration page (under
Issues), not the project Issue types page.
ii. Click Edit for the new Person issue type (under Operations).
iii. Click the current avatar or select image for Issue Type Avatar.
iv. The ideal avatar for this issue type would be a person and you
could browse and use your own custom avatar at your
organization. Here we'll choose one of the default avatars. Click

the heart avatar.
v. Click Update.
i. Test the new issue type:

i. Create a new issue and select Person for the Issue Type. Click
Next.
You need to specify which project to create the issue in when you
create an issue from JIRA Administration.
ii. Notice it's the same create screen as Task issue type. Enter a
Summary e.g. Test 4 and click Create.
j. On the issue page, click View Workflow and confirm it's the same
workflow as for a Task issue type (the one that you edited earlier).

k. Close the workflow screen.
2. Change the workflow for an issue type:

For this new Person issue type we'll need a new workflow. This will be different
from the Task workflow that we edited earlier so it's easier to start with the
original default workflow that came with this project template. Recall you saved
the original workflow earlier after you edited the workflow.
a. Navigate to the Workflows Human Resources administration page. You
see all three issue types are associated with the HR: Project
b. Click Add Workflow – Add existing.

c. Select Original HR: Project Management Workflow and click Next.
d. Select Person and click Finish.
e. Confirm the Task and Sub-task issue types are using HR: Project
Management Workflow and Person issue type is using Original HR:
Project Management Workflow before publishing.

f. Click Publish.
g. Here it shows which status will be changed. In this case, REOPENED will
be change to To Do. Click Associate.
h. Once it's finished migrating issues to the new workflow, click

Acknowledge.
i. Create another issue of type Person and view Workflow to verify it's now
using the original workflow.

j. Close the Workflow page.
Optional Exercise 5 – Updating a Workflow & Viewing Activity

1. Edit the workflow for Person issue type:
a. Think about what workflow you would need for the process for managing
a new job applicant. At Teams In Space, you would speak to the
stakeholders to find out what the process is for this.
b. First map it out on paper. What transitions (how) and statuses (where)
would you need? For example, you may have a Make Offer transition,
which goes to a With Candidate status.
c. Update the Original HR: Project Management Workflow to reflect your
new process.
d. Test your new workflow.
2. View all your activity on your System Dashboard.

Recall that when users log in, by default they see the System Dashboard. We
configured that in an earlier lab but back then we didn't have much activity. Now
you've been creating issues you can see activity in your Activity Stream gadget.
1. Edit the workflow for Person issue type:
a. Think about what workflow you would need for the process for managing
a new job applicant. At Teams In Space, you would speak to the
stakeholders to find out what the process is for this.

b. First map it out on paper. What transitions (how) and statuses (where)
would you need? For example, you may have a Make Offer transition,
which goes to a With Candidate status.
c. Update the Original HR: Project Management Workflow to reflect your
new process.
d. Test your new workflow.
2. View all your activity:

Recall that when users log in, by default they see the System Dashboard. We
configured that in an earlier lab but back then we didn't have much activity. Now
you've been creating issues you can see activity in your Activity Stream gadget.
a. Click Dashboards – View System Dashboard.
b. Now you can see all your recent issue creation activity in the Activity
Stream gadget.

Lab 5 Appendix
Further reading
Reference URL
Defining a http://go.atlassian.com/define_project
project
Building http://blogs.atlassian.com/2013/10/building-workflow-awesome
workflows
Using JIRA to http://blogs.atlassian.com/2014/05/life-runs-jira-sommelier-edition

manage a
wine cellar
Best Practices
Creating a long You created the key You can change the default
difficult to HMN_RSS for the new Human project key but if you do,
remember project Resources project but users choose a key that is
key results in users of this project are complaining descriptive and easy to type.
getting frustrated because they can't remember Users will often use the issue
because they the key to easily find issues. key to find an issue and you
cannot easily want to make it as easy as
search for issues. possible for them so don't use
overly long keys. The key can
be changed after project
creation but it is not a trivial
task.
Not being able to You updated a complex Always save a backup copy of
revert back to the workflow and made many a workflow when you edit. That
original workflow changes. When you tested it way you can always go back to
when you've made you realized you made a the original if you make
mistakes or number of mistakes. It would mistakes.
requirements have be easier to revert back to the
changed. original workflow and start
again than try to fix the
mistakes but you didn't make
a backup!

Screens the Users are frustrated with filling Remove unused fields to help
contain too many out a long Create Issue screen simplify the screens for users
fields will make as there are too many fields and make them easier to use.
users frustrated and they don't know what half
and they'll skip of them are. So they just leave
filling out most of the form blank and
important fields. you miss out on getting data
on some of the important
fields so gadgets and reports
don't work well.

Lab 6 – Configuring Project Roles & Permissions
Scenario
You've created the Human Resources project and configured the workflow, issue types
and screens. Now you need to configure the project roles and permissions to control
who does what in this project. The project administrator has decided that only members
of the Human Resources group should be able to create issues in this project. To
accomplish this you create a new project role and a new permission scheme.
As the JIRA administrator and the project administrator, you perform the following
tasks:
• Make the project lead the project administrator
• Update the Default Permission Scheme
• Set the default assignee
• Create a project role
• Copy the default permission scheme
• Associate the new permission scheme with the project
• Update the new permission scheme
• Add a group to a project role
• Optional – View other role and permission information
Exercise 1 – Assigning Project Roles

page 138.
1. Make the project lead the project administrator:

a. As the JIRA administrator, Dakota Jones (djones/Charlie!), navigate to
the Human Resources Users and roles project administration page.
The default configuration of a project has one project administrator role

(Administrators) assigned to the jira-administrators group. The default
permission and notification schemes are already configured to use this
role.
Teams In Space wants the project lead to be the project administrator by

default for any new Business project. The most important task of the
project administrator, assigning users to project roles, is typically one
that would be done by the project lead. For the Human Resources
project, we've already assigned Sophie Nguyen as the project lead.
There are two ways we could make her project administrator:
i. Add Sophie to the Administrators project role on this page.
ii. Update the Default Permission Scheme and assign the Administer
Projects permission to the project lead role.

Which one incurs less administrative overhead given that Teams In
Space wants all project leads to be the project administrator?
Answer: It makes more sense to update the Default Permission scheme.

The Default Permission Scheme is used for any new Business project. So
any changes we make to this default scheme will be shared with all new
Business projects that are created. So when a new Business project is
created, the project lead will automatically have the Administer Projects
permission.
b. Update the Default Permission Scheme:

i. Navigate to the Human Resources Permissions project
administration page and view the default permissions. See how
the default permission scheme associates various permissions
with various roles.
ii. Edit permissions and you are taken to JIRA Administration to edit
the Default Permission Scheme. Add the project lead role to the
Administer Projects permission.
Sophie can now update this project's details (name, description,

avatar, and URL). She can also edit the project lead and project
role memberships, change the project type, and define
components and versions. She cannot however edit the project's
schemes. Only the JIRA administrator can do that. Managing
project role membership is the most important responsibility.
c. Return to the Human Resources Users and roles project administration

page.
Why don't you see Sophie listed here as the project administrator?
Answer: Because this shows the members of the project role,

Administrators. You can only add users and groups to project roles. You
cannot add other project roles to a project role. Instead we've given
project leads the Administer Project permission.
What would you need to do now (at Teams In Space) if you had a special
project where the project lead and project administrator were different
people?
Answer: You would need to make a copy of the Default Permission

Scheme and associate it with the project. Then you would update the
new permission scheme and remove the project lead from the Administer
Projects permission. Then you could go to the project's Users and roles
administration page and add the new project administrator to the
Administrators role.

2. Set the Default Assignee:
It’s important to set the Default Assignee correctly for your project, as this
controls who is tasked with a new issue when it is created.
a. Log out as Dakota and log in as Sophie, the new project administrator
(snguyen/Charlie!).
b. Navigate to Human Resources project administration. You would not
have access to this as just a project member.
c. Navigate to the Users and roles project administration page. Here you
see the Default Assignee is Unassigned.
When a new issue is created, if the assignee is not specified, the

project's Default Assignee is used. You can either choose Project Lead
or leave it as Unassigned. The Unassigned option is only available if the
Allow Unassigned Issues setting in JIRA’s General Configuration is set to
ON (this is the default). Additionally, settings in the Component section of
the project's configuration may override the Default Assignee for any
issues that have the Component field set.
d. Edit the project defaults and select the project lead as the Default
Assignee.
e. Navigate to the Human Resources Summary administration page. You
can also view these two settings in the Roles section of this page.
3. Optionally, verify the default assignee for the project.

a. Log out as Sophie and log back in as Luis Beck (lbeck/Charlie!), a
member of the Human Resources group.
b. Create an issue for this project then view the issue.
Who is the issue assigned to?
Answer: The issue should be assigned to Sophie Nguyen who is the

Default Assignee for this project.

1. Make the project lead the project administrator:
a. As the JIRA administrator, Dakota Jones (djones/Charlie!), navigate to
the Human Resources Users and roles project administration page.
The default configuration of a project has one project administrator role

(Administrators) assigned to the jira-administrators group. The default
permission and notification schemes are already configured to use this
role.
Teams In Space wants the project lead to be the project administrator by

default for any new Business project. The most important task of the
project administrator, assigning users to project roles, is typically one
that would be done by the project lead. For the Human Resources
project, we've already assigned Sophie Nguyen as the project lead.
There are two ways we could make her project administrator:
i. Add Sophie to the Administrators project role on this page.
ii. Update the Default Permission Scheme and assign the Administer
Projects permission to the project lead role.
Which one incurs less administrative overhead given that Teams In

Space wants all project leads to be the project administrator?
Answer: It makes more sense to update the Default Permission scheme.

The Default Permission Scheme is used for any new Business project. So
any changes we make to this default scheme will be shared with all new
Business projects that are created. So when a new Business project is
created, the project lead will automatically have the Administer Projects
permission.
b. Update the Default Permission Scheme:

i. Navigate to the Human Resources Permissions project
administration page. Scroll down and view the default
permissions. See how the default permission scheme associates
various permissions (for the project, issues, comments, etc.) with
various roles. Click Actions > Edit permissions.

ii. Now you are taken to JIRA Administration to edit the Default
Permission Scheme. We want to add a role to the Administer
Projects permission, so click Edit in that row.
iii. The Administer Projects permission will be selected for you. Click
Show More to see all the options then select project lead as the
role to assign this permission to. Click Grant.
iv. Confirm the project lead role is now assigned the Administer
projects permission.

Sophie can now update this project's details (name, description,
avatar, and URL). She can also edit the project lead and project
role memberships, change the project type, and define
components and versions. She cannot however edit the project's
schemes. Only the JIRA administrator can do that. Managing
project role membership is the most important responsibility of a
project administrator.
c. Return to the Human Resources Users and roles project administration

page.
Why don't you see Sophie listed here as the project administrator?
Answer: Because this shows the members of the project role,

Administrators. You can only add users and groups to project roles. You
cannot add other project roles to a project role. Instead we've given
project leads the Administer Project permission.
What would you need to do now (at Teams In Space) if you had a special
project where the project lead and project administrator were different
people?
Answer: You would need to make a copy of the Default Permission

Scheme and associate it with the project. Then you would update the
new permission scheme and remove the project lead from the Administer
Projects permission. Then you could go to the project's Users and roles
administration page and add the new project administrator to the
Administrators role.
2. Set the Default Assignee:

It’s important to set the Default Assignee correctly for your project, as this
controls who is tasked with a new issue when it is created.
a. Log out as Dakota and log in as Sophie, the new project administrator
(snguyen/Charlie!).
b. Click Continue, Next, and Skip quick tour to sign in as a new user.

c. Click Explore the current projects.
d. Click Human Resources to navigate to that project then click the

Administration cog icon at the bottom of the sidebar. Now you are in
project administration, which you would not have access to as just a
project member.
e. Navigate to the Users and roles project administration page. Here you
see the Default Assignee is Unassigned.
When a new issue is created, if the assignee is not specified, the

project's Default Assignee is used. You can either choose Project Lead
or leave it as Unassigned. The Unassigned option is only available if the
Allow Unassigned Issues setting in JIRA’s General Configuration is set to
ON (this is the default). Additionally, settings in the Component section of
the project's configuration may override the Default Assignee for any
issues that have the Component field set.
f. Click Edit defaults.
i. For Default Assignee, select Project Lead.

ii. Click Update.
g. Navigate to the Human Resources Summary administration page. You

can also view these two settings in the Roles section of this page.
3. Optionally, verify the default assignee for the project:

a. Log out as Sophie and log back in as Luis Beck (lbeck/Charlie!), a
member of the Human Resources group.
b. Create an issue for this project.
i. Choose either Task or Person as the issue type.
ii. Enter a Summary of your choosing e.g. Test 6.
iii. Click Create.
c. Click Issues then select the issue you just created under RECENT
ISSUES.

d. View the issue.
Who is the issue assigned to?
Answer: The issue should be assigned to Sophie Nguyen who is the

Default Assignee for this project.
Exercise 2 – Creating Project Roles & Configuring Project

Permissions
Page 146.
The Human Resources project lead wants only the members of the Human
Resources group to be able to create issues in the Human Resources project.
Members of other departments will only be able to view issues in this project.
1. Create project role:

a. Log out and log back in as the JIRA administrator, Dakota
(djones/Charlie!).
Project administrators can add users to project roles but they cannot
create new project roles. This needs to be done by a JIRA administrator.
b. Navigate to the Project roles JIRA administration page and add a

project role named Members. Optionally enter the description - This
project role represents users who are members of a project and can
create issues in the project.
c. View the new role. There's a link to Manage Default Members where you
can define default members. We won't define any default members, as
the members will be different for each project this is used in.
2. Copy the default permission scheme:

Now we need to set up the permissions for this project so only members can
create issues.
Can the project administrator edit the permissions for her project?

Answer: No, she cannot edit the permissions for her project; only the
JIRA administrator can edit permission schemes.
As the JIRA administrator, could we simply edit the Default Permission

Scheme to update the permissions for the Human Resources project?
Answer: It depends. The Default Permission Scheme is used for any new
Business project. So any changes we make to this default scheme will be
shared with all new Business projects that are created. If this is a change
all Business projects will use, then you could edit the default scheme.
However, if it's a change you think will only apply to this one project (or
to all HR projects) then you need to make a copy of the default scheme
and edit the copy. At Teams In Space, other Business projects may want
other users who don't work in their project to be able to create issues.
So we'll make a copy, associate the copy with our project, and edit that.
a. Navigate to the Permission Schemes JIRA administration page and

copy the Default Permission Scheme row (that's associated with the
Human Resources project).
b. Edit Copy of Default Permission Scheme and name it HR Permission
Scheme with a description: Permission scheme to use with the
Human Resources project
If you're going to have a lot of projects and a lot of project schemes,

always use a descriptive name and add a description so you can easily
see what each one is.
3. Associate new permission scheme with the project:

a. Now we'll associate the new permission scheme with the Human
Resources project. Navigate back to the Human Resources Permissions
administration page and select to use a different scheme (under Actions).
b. Associate the HR Permission Scheme.
4. Update the permissions in the scheme:

Now we'll update the permissions so that only users who belong to the
Members role can create issues.
The core usage for roles is for permission and notification schemes. While
you could assign permissions and notifications to users and groups directly,
roles are more flexible and sustainable.
a. On the Human Resources Permissions administration page, edit

permissions:
i. View the Create Issues permission. Here we can see that any
logged in user has permission to create an issue.
ii. Edit the Create Issues permission and review the different roles,
users, groups, etc. you can assign this permission to.
Could you assign this permission to just the JIRA Core users?
Answer: Yes, you could. If you select Application role you will
see all the JIRA applications that are installed. You might
decide you want all Core (Business) users to be able to create
issues for a particular project. The default, Any logged in user,
means any user from any JIRA application who's logged in.
(Don't change the setting here.) In this situation we want to use
our project role, Members.
iii. Add the Members project role (the new project role you created
earlier).
b. Delete the Application Role (Any logged in User) to remove other users
who are not project members from the Create Issues permission. Now
only the Members project role can create issues for this project.
You may also want to update other permissions such as Edit Issues,
Assign Issues, Resolve Issues, etc. to fully protect the issues in this
project. For this lab, we'll just change Create Issues.
Who can delete issues?
Answer: By default only the project administrator can delete issues.
5. Add a group to a project role:

a. Project administrators are the ones that add users to a project role. So
log out and log in as Sophie (snguyen/Charlie!), the project
administrator and project lead.
b. Navigate to the Human Resources Users and roles project
c. Add the Human Resources group to the Members role.
6. Verify project roles and permissions:

a. Log back in as Dakota (djones/Charlie!) and navigate to the Permission
helper administration page.
The Permission helper is very useful for verifying permissions or

troubleshooting permission issues.
b. Check the Create Issues permission for a Ryan Lee who is not a
member of the Human Resources project. Choose one of your HR test
issues. He should not have the permission.
c. Now check the Create Issues permission for a Human Resources project
member, Luis beck. He should have the permission.
d. Optionally, test permissions by logging in as various users:
iv. First log out and log back in as Ryan Lee (rlee/Charlie!), who's in
the Development group and not a member of the Human
Resources group.
v. Try to create a new issue for the Human Resources project.
Can Ryan create an issue?
Answer: In fact Ryan cannot create any issues. This is because

he no longer has the permission to create issues for the Human
Resources project. Also there are no Software projects created
yet so there's no project for him to create an issue in. If he can
create a Human Resources issue, go back and check your
permissions for the project.
vi. Now log out and log back in as Luis Beck (lbeck/Charlie!) and try
to create an issue for the Human Resources project.
Can Luis create an issue?
Answer: Yes, Luis can create an issue in the Human Resources

project because he belongs to the Members project role. If he
cannot create a Human Resources issue, go back and check your
To start the next lab, go to page 155.
The Human Resources project lead wants only the members of the Human
Resources group to be able to create issues in the Human Resources project.
Members of other departments will only be able to view issues in this project.
1. Create project role:

a. Log out and log back in as the JIRA administrator, Dakota
(djones/Charlie!).
Project administrators can add users to project roles but they cannot
create new project roles. This needs to be done by a JIRA
administrator.

b. Navigate to the Project roles JIRA administration page.
c. Scroll down the page to the Add Project Role section and enter the
new project role details:
i. Name: Members
ii. Optional Description: This project role represents users who
are members of a project and can create issues in the
project
iii. Click Add Project Role.
d. View the new role. There's a link to Manage Default Members where
you can define default members. We won't define any default
members, as the members will be different for each project this is
used in.
2. Copy the default permission scheme:

Now we need to set up the permissions for this project so only members can
create issues.

Can the project administrator edit the permissions for her project?
Answer: No, she cannot edit the permissions for her project; only the
JIRA administrator can edit permission schemes.
As the JIRA administrator, could we simply edit the Default Permission

Scheme to update the permissions for the Human Resources project?
Answer: It depends. The Default Permission Scheme is used for any new
Business project. So any changes we make to this default scheme will be
shared with all new Business projects that are created. If this is a change
all Business projects will use, then you could edit the default scheme.
However, if it's a change you think will only apply to this one project (or
to all HR projects) then you need to make a copy of the default scheme
and edit the copy. At Teams In Space, other Business projects may want
other users who don't work in their project to be able to create issues.
So we'll make a copy, associate the copy with our project, and edit that.
a. Navigate to the Permission Schemes JIRA administration page.

b. In the Default Permission Scheme row (that's associated with the Human
Resources project) click Copy.
c. Click Edit in the Copy of Default Permission Scheme row.
d. Give the new permission scheme a new name and description:

i. Name: HR Permission Scheme
ii. Description: Permission scheme to use with the Human
Resources project
iii. Click Update.

e. The new scheme now has a descriptive name and description.
If you're going to have a lot of projects and a lot of project schemes,

always use a descriptive name and add a description so you can easily
see what each one is.
3. Associate new permission scheme with the project:

a. Now we'll associate the new permission scheme with the Human
Resources project. Navigate back to the Human Resources Permissions
b. Click the Actions drop down and select Use a different scheme.
c. Select the HR Permission Scheme and click Associate.
d. Now you should see the HR Permission Scheme being used.

4. Update the permissions in the scheme:
Now we'll update the permissions so that only users who belong to the
Members role can create issues.
The core usage for roles is for permission and notification schemes. While
you could assign permissions and notifications to users and groups directly,
roles are more flexible and sustainable.
a. On the Human Resources Permissions page, click Actions > Edit

permissions.
b. Edit the Create Issues permission:

i. Scroll down to the Create Issues permission. Here we can see
that any logged in user has permission to create an issue.
ii. Click Edit in the Create Issues row.
iii. Click Show more and review the different roles, users, groups,
etc. you can assign this permission to.
Could you assign this permission to just the JIRA Core users?
Answer: Yes, you could. If you click Application role then the
dropdown you will see all the JIRA applications that are
installed. You might decide you want all Core (Business) users
to be able to create issues for a particular project. The default,
Any logged in user, means any user from any JIRA application
who's logged in. (Don't change the setting here.) In this
situation we want to use our project role, Members.
iv. Click the radio button to select Project Role then select
Members (the new project role you created earlier). Click Grant.
Grant.

c. Now we need to remove other users who are not project members from
the Create Issues permission. Click Remove.
d. Select Application Role and click Remove.
e. Now you should see that only the Members project role can create
issues for this project.

You may also want to update other permissions such as Edit Issues,
Assign Issues, Resolve Issues, etc. to fully protect the issues in this
project. For this lab, we'll just change Create Issues.
Who can delete issues?
Answer: By default only the project administrator can delete issues.
5. Add a group to a project role:

a. Project administrators are the ones that add users to a project role. So
log out and log in as Sophie (snguyen/Charlie!), the project
administrator and project lead.
b. Navigate to the Human Resources Users and roles project
c. Click Add users to a role.
i. Search for Human Resources and select that.
ii. Click the Role dropdown and select your new role, Members.
iii. Click Add.
d. Verify the Human Resources group is now in the new Members role.

6. Verify project roles and permissions:
a. Log back in as Dakota (djones/Charlie!) and navigate to the
Permission helper administration page (under System).
The Permission helper is very useful for verifying permissions or

troubleshooting permission issues.
b. Check the permission for a user who is not a member of the Human
Resources project.
i. User: Ryan Lee
ii. Issue: Enter or choose one of your HR test issues
iii. Permission: Create Issues
iv. Click Submit.
c. Now check the Create Issues permission for a Human Resources project
member, Luis beck.

d. Optionally, test permissions by logging in as various users:
i. First let's test this as a user who is not a member of the Human
Resources project. Log out and log back in as Ryan Lee
(rlee/Charlie!), who's in the Development group.
ii. Try to create a new issue for the Human Resources project.
Can Ryan create an issue?
Answer: In fact Ryan cannot create any issues. This is because

he no longer has the permission to create issues for the Human
Resources project. Also there are no Software projects created
yet so there's no project for him to create an issue in. If he can
create a Human Resources issue, go back and check your
iii. Now let's test this as a Human Resources project member. Log
out and log back in as Luis Beck (lbeck/Charlie!) and try to
create an issue for the Human Resources project.
Can Luis create an issue?
Answer: Yes, Luis can create an issue in the Human Resources

project because he belongs to the Members project role. If he
cannot create a Human Resources issue, go back and check your

Optional Exercise 3 – Viewing Other Role & Permission
Information
1. As the JIRA administrator, Dakota (djones/Charlie!), navigate to the Human
Resources Components administration page and view who you can assign as
the Default Assignee.
We don't have any components defined for this project but if you did,
you could assign someone to the Component Lead role and then choose
the Default Assignee. By default it's the project lead.
2. View other useful ways to see role and permissions information:

a. Navigate to the Project roles JIRA administration page.
b. If you have project roles that are used in multiple projects and schemes,
it's good to be able to see which projects and schemes they're used in.
Click the View Usage link for the Members role.
c. Here you can see that the Members project role you created is used in
the HR Permission scheme, which is associated with the Human
Resources project. If you click the View link for the Project Role
Members it takes you to the Users and roles page where you can see the
role members.
d. To view what project roles a particular user has, navigate to the Users
JIRA administration page.
e. For Luis Beck and click the ellipses (…) then select View project roles.
You can see he's a member of the Members project role.
1. View the Default Assignee for project components:
a. As the JIRA administrator, Dakota (djones/Charlie!), navigate to the
Human Resources Components administration page.
b. Click the Default Assignee drop down.
We don't have any components defined for this project but if you did,
you could assign someone to the Component Lead role and then choose
the Default Assignee. By default it's the project lead.

2. View other useful ways to see role and permissions information:
a. Navigate to the Project roles JIRA administration page.
b. If you have project roles that are used in multiple projects and schemes,
it's good to be able to see which projects and schemes they're used in.
Click the View Usage link for the Members role.
c. Here you can see that the Members project role you created is used in
the HR Permission scheme, which is associated with the Human
Resources project. If you click the View link for the Project Role
Members it takes you to the Users and roles page where you can see the
role members.
d. To view what project roles a particular user has, navigate to the Users
JIRA administration page.
e. Scroll down to Luis Beck and click the ellipses (…) then select View
project roles.
f. You can see he's a member of the Members project role.

Lab 6 Appendix
Further reading
Reference URL
Managing http://go.atlassian.com/project_perms
users
Managing http://go.atlassian.com/project_roles
groups
Best Practices
Can't find projects We have hundreds of If you're going to have a lot of

easily. projects but some of the projects and a lot of project
names are very short and schemes, always use a
cryptic and they don't have descriptive name and add a
descriptions so we can't find description so you can easily
the projects easily. see what each one is.
If the Default I have a Business project The Default Permission Scheme

Permission with very specific is used for any new Business
Scheme is requirements that are totally project. So any changes we
updated it affects different from all other make to this default scheme will
every project that Business projects. I've be shared with all new Business
is using it. updated the Default projects that are created. If this
Permission Scheme for that is a change all Business projects
project but I just realized that will use, then you could edit the
a lot of other projects use default scheme. However, if it's
the Default Permission a change you think will only
Scheme apply to this one project then
you need to make a copy of the
default scheme and edit the
copy. Then associate the copy
with the project, and edit that.
Assigning users or I've created copies of the Use roles in permission and
groups to Default Notification Scheme notification schemes. While you
permission or for each of my new projects could assign permissions and
notification and I've updated each notifications to users and
schemes means scheme adding just the groups directly, roles are more

you need more users for each of the flexible and sustainable. Also
schemes, which projects. But it's a lot of when you use roles you can
incurs more work to do this and keep delegate some administrative
administrative them all maintained. And I've tasks to the project
overhead and noticed performance is not administrator – they can add
possible as good as it was. their users to their project roles.
performance
degradation.

Lab 7 – Sharing & Customizing Project Configuration
Scenario
You've created and configured the Human Resources project to satisfy its members.
Human Resources stakeholders have now requested another project to deal with
Payroll issues. They want it configured almost exactly the same as the Human
Resources project. Here you create the new project but instead of going through all the
configuration changes you made in earlier labs, you share the configuration of the
You also explore other ways to share configuration by sharing default schemes and
sharing just one scheme. You see the consequences and benefits of sharing schemes.
You also learn the importance of backing up schemes and what happens when a
project is deleted.
As the JIRA administrator, Dakota Jones, you perform the following tasks:
• Create a project by sharing another project's configuration
• Edit a project scheme that's shared between projects
• Troubleshoot a role issue
• Optional:
o Backup then edit a widely shared default scheme
o Delete a project and see what happens to its schemes
o Share a scheme between projects
Here is a summary of the common scheme scenarios:

• Create a project and share another project's configuration – Often projects
have similar requirements. If you want a project that's based on the
configuration of an already existing project, you create a new project with
shared configurations. This means you share all the schemes and any changes
made to these schemes will affect both projects. You do this in this lab.
• Share a scheme between projects – Sometimes there will be a similar
requirement between projects. To meet this you could share just one scheme
between the projects. You can optionally do this in this lab.
• Edit a widely shared default scheme – Sometimes you have to modify a widely
shared scheme because of new requirements. This could be a new company
policy or, in this case, users complaining about too many notification emails.
You can optionally edit a default scheme in this lab.
• Use a custom scheme for one project – Sometimes you need to have a
scheme just for one project because it has unique requirements. To do this you
copy a scheme (a default scheme or one from another project), associate it with
a project, and then edit it for just that project. You did that in the last module's
lab when you copied the default permission scheme and edited it for your
project.
• Create a project with custom configuration – If you have a project that has
unique requirements for the whole project then you need all custom schemes.
When you create a project, by default (if you don't select Create with shared
configuration), it automatically creates a fresh copy of the workflow, issue type,
screen, and issue type screen schemes for use just in that project. But the

project uses the default permission, notification, and field configuration
schemes. You would need to copy these defaults and associate them with your
new project to get these custom schemes.
Generally you want to avoid having too many schemes as that could require a
lot of work to maintain them. You want to share schemes as much as possible
where you have a reasonable belief that the shared configuration will stay in
sync. Even if things go out of sync, most schemes can be easily copied and
reverted if necessary. Consider sharing schemes for different project types or
Departments. For example, Development may have a set of schemes that are
shared for all Development projects.
Exercise 1 – Creating a Project with Shared Configuration

Page 162.
1. Create a project by sharing another project's configuration:

a. Log in to JIRA as the JIRA administrator Dakota Jones (djones/Charlie!).
b. Human Resources want another project to deal with Payroll issues.
Create a new project and select Create with shared configuration (on
the bottom of the first page).
c. Choose the Human Resources project to share configurations with.
Note the message that appears. Creating a project like this means it
shares its configuration schemes so any change to one project's
configuration will affect the other project.
d. Continue and enter the project details:

i. Name: Payroll
ii. Key: PAY
iii. Project Lead: Luis Beck
2. View configuration of new project:

a. Navigate to the Payroll project's Issue types administration page. Here
we see the HR: Project Management Issue Type Scheme, which contains
the Person issue type we created in the Human Resources project.
What workflows do the Task and Person issue types use? Are they
shared?
Answer: The Task issue type uses the HR: Project Management
Workflow and the Person issue type uses the Original HR: Project
Management Workflow. Both of these are shared between the Payroll
and Human Resources projects.

Are there any other schemes that are shown here that are shared
between the two projects?
Answer: Yes, the HR: Project management Screen Scheme is shared

between the two projects.
Are there any configurations shown here that are not shared just
Answer: Yes, the Default Field Configuration is not shared solely

between the two projects as it's a system default and is shared by these
two projects and any other projects that have not changed their field
configuration and any new projects that will be created.
b. Navigate to the Payroll project's Notifications administration page. Note

that both projects are now using the Default Notification scheme so any
changes we make to this scheme will apply to ALL new projects that are
created.
Is this Notification scheme shared solely by these two projects?
Answer: For now it is – see SHARED BY 2 PROJECTS next to the

scheme name. But this is because these are the only two projects that
have been created. This is the Default Notification Scheme and it will be
shared with every new project that's created.
c. View the names of the projects sharing this scheme.

d. Navigate to the Payroll Permissions administration page.
Why isn't it using the Default Permission scheme? New projects usually
use that.
Answer: New projects use the default permission scheme when the
project is created the default way. But we created this project using the
Create with shared configuration option and chose to share the
configuration of the Human Resources project, which uses HR
Permission Scheme.
A quick way to see which schemes are shared and which are not is to
navigate to the project's Summary page and view the schemes listed
there.

1. Create a project by sharing another project's configuration:
a. Log in to JIRA as the JIRA administrator Dakota Jones (djones/Charlie!).
b. From the main menu click Projects > Create Project.
c. Human Resources want another project to deal with Payroll issues. At
the bottom of the Create Project page, click Create with shared
configuration.
d. Choose the Human Resources project to share configurations with.
Note the message that appears. Creating a project like this means it
shares its configuration schemes so any change to one project's
configuration will affect the other project.
e. Click Next.
f. Enter the project details:

i. Name: Payroll
ii. Key: PAY
iii. Project Lead: Luis Beck
iv. Click Submit.
2. View configuration of new project:

a. Navigate to the Payroll project's Issue types administration page. Here
we see the HR: Project Management Issue Type Scheme, which contains
the Person issue type we created in the Human Resources project.
What workflows do the Task and Person issue types use? Are they
shared?
Answer: The Task issue type uses the HR: Project Management
Workflow and the Person issue type uses the Original HR: Project
Management Workflow. Both of these are shared between the Payroll
and Human Resources projects.
Are there any other schemes that are shown here that are shared
Answer: Yes, the HR: Project management Screen Scheme is shared

between the two projects.

Are there any configurations shown here that are not shared just
Answer: Yes, the Default Field Configuration is not shared solely

between the two projects as it's a system default and is shared by these
two projects and any other projects that have not changed their field
configuration and any new projects that will be created.
b. Navigate to the Payroll project's Notifications administration page.
Is this Notification scheme shared solely by these two projects?
Answer: For now it is – see SHARED BY 2 PROJECTS next to the

scheme name. But this is because these are the only two projects that
have been created. This is the Default Notification Scheme and it will be
shared with every new project that's created.
c. To confirm which projects are using this scheme click 2 PROJECTS in

the SHARED BY 2 PROJECTS box.

d. Navigate to the Payroll Permissions administration page.
Why isn't it using the Default Permission scheme? New projects usually
use that.
Answer: New projects use the default permission scheme when the
project is created the default way. But we created this project using the
Create with shared configuration option and chose to share the
configuration of the Human Resources project, which uses HR
Permission Scheme.
A quick way to see which schemes are shared and which are not, is to
navigate to the project's Summary page and view the schemes listed
there.
Exercise 2 – Editing a Shared Project Scheme

Page 167.
1. Edit a project scheme that's shared between projects:

The Human Resources department (which overseas both the Human Resources
and Payroll projects) have decided they want to restrict permissions on moving
issues to just the project leads for these two projects. To do so we need to edit
the HR Permission Scheme.
a. On the Payroll Permissions administration page, edit the permissions for
the HR Permission scheme.
b. Add the Project Lead to the Move Issues permission.
c. Delete Application role (Any logged in user) from Move Issues. Now
only the user with the project lead role can move issues.
2. Test the new permission:

a. Log out and log back in as Payroll project lead, Luis Beck
(lbeck/Charlie!) and create an issue in the Payroll project.

Could Luis create an issue in the Payroll project?
Answer: No, the only project that's available is Human Resources.
Why can't Luis create issues for the Payroll project?
Log back in as Dakota (djones/Charlie!) and open up two browser

windows. In one window navigate to the Human Resources
project's Users and roles administration page and in the other
window navigate to the Payroll Users and roles administration
page. What's different?
Answer: The Payroll project only has the Administrators role defined. It
doesn't have the Members role. Recall, that you set this up and edited
the permissions for this role so only members of this group could create
issues. You need to add users to roles for each project because each
project will have different users. But you can use project roles already
defined. In this case we'll use the Members project role we defined
earlier but we'll assign it different members.
b. Add users to a project role:

i. On the Payroll Users and roles administration page, add users to
a role.
ii. Add the members of this project – Luis Beck, Sophie Nguyen,
and Rosemary Silva to the Members role.
You define the project role once but you can select different
members for each project the role is used in.
c. Now that we've sorted out the project role, let's get back to testing the
Move Issues permission. Log out and back in as the Payroll project lead,
Luis Beck (lbeck/Charlie!).
d. Create an issue in the Payroll project. This should now succeed. If it
didn't, go back and check you have the right role members for each
project.
e. Open the issue you just created. Click More and select Move.
f. Click Cancel. If he did not have Move Issues permission we would not
see this option so we have verified he has that permission.
g. Now open an issue from the Human Resources project. Click More and
confirm you do not have permission to move issues in the Human
Resources project.
h. Now perform the same test as the Human Resources project lead,
Sophie Nguyen (snguyen/Charlie!). See if you get the Move option for
both a Human Resources issue and a Payroll issue.
What did you find?

Answer: As expected Sophie could move a Human Resources issue and
could not move a Payroll issue.
Here we see the power of roles. You could have assigned the Move
Issues permission to a particular user or group but that would mean you
would have to have a separate Permission scheme for each project
because it was customized for that project. Instead by assigning the
permission to a project role, whoever has that role in a project, will get
that permission. This means you can share schemes and save a lot of
work. By using project roles you can use fewer permission schemes and
that's good for administrative overhead and performance.
1. Edit a project scheme that's shared between projects:
The Human Resources department (which overseas both the Human Resources
and Payroll projects) have decided they want to restrict permissions on moving
issues to just the project leads for these two projects. To do so we need to edit
the HR Permission Scheme.
a. On the Payroll Permissions administration page, click Actions > Edit
Permissions.
b. Edit the Move Issues permission.

c. Select Project Lead and click Grant.

d. In the Move Issue row, click Remove and remove Application role (Any
logged in user). Now only the user with the project lead role can move
issues.
2. Test the new permission:

a. Log out and log back in as Payroll project lead, Luis Beck
(lbeck/Charlie!) and create an issue in the Payroll project.
Could Luis create an issue in the Payroll project?
Answer: No, the only project that's available is Human Resources.
Do you know why Luis cannot create issues for the Payroll project?
Log back in as Dakota (djones/Charlie!) and open up two browser

windows. In one window navigate to the Human Resources
project's Users and roles administration page and in the other
window navigate to the Payroll Users and roles administration
page. What's different?
Human Resources Users and roles page:

Payroll Users and roles page:
Answer: The Payroll project only has the Administrators role defined. It
doesn't have the Members role. Recall, that you set this up and edited
the permissions for this role so only members of this group could create
issues. You need to add users to roles for each project because each
project will have different users. But you can use project roles already
defined. In this case we'll use the Members project role we defined
earlier but we'll assign it different members.
b. Add users to a project role:

i. On the Payroll Users and roles administration page, click Add
users to a role.
ii. Search for and add the members of this project – Luis Beck,
Sophie Nguyen, and Rosemary Silva. Then select Members for
the role and click Add.
iii. Now you see the members of the Payroll project in the Members
project role.

You define the project role once but you can select different
members for each project the role is used in.
c. Now that we've sorted out the project role, let's get back to testing the
Move Issues permission. Log out and back in as the Payroll project lead,
Luis Beck (lbeck/Charlie!).
d. Create an issue in the Payroll project. This should now succeed. If it
didn't, go back and check you have the right role members for each
project.
e. Open the issue you just created by clicking Issues and selecting the
issue under Recent Issues.
f. Click More and confirm you see Move. If he did not have Move Issues
permission we would not see this option so we have verified he has that
permission.

g. Now open an issue from the Human Resources project. Click More and
confirm he do not have permission to move issues in the Human
Resources project.
h. Now perform the same test as the Human Resources project lead,
Sophie Nguyen (snguyen/Charlie!). See if you get the Move option for
both a Human Resources issue and a Payroll issue.
What did you find?
Answer: As expected Sophie could move a Human Resources issue and

could not move a Payroll issue.
Here we see the power of roles. You could have assigned the Move
Issues permission to a particular user or group but that would mean you
would have to have a separate Permission scheme for each project
because it was customized for that project. Instead by assigning the
permission to a project role, whoever has that role in a project, will get
that permission. This means you can share schemes and save a lot of
work. By using project roles you can use fewer permission schemes and
that's good for administrative overhead and performance.

Optional Exercise 3 – Backing Up & Editing the Default
Notification Scheme
the next page.
Many Teams In Space users are complaining of too many JIRA notification emails.
Most of the stakeholders have agreed that users who report issues don't want to be
sent notifications on so many events. They've requested to stop Reporters from
getting notifications when a comment is edited on an issue and when an issue is
moved.
1. Backup a default scheme:
Before editing a widely used scheme and especially a system default

scheme, you should save a copy in case you make mistakes or the changes
turn out to be unpopular. Then you can use that as a reference if you need to
undo your changes. In this case you're only making a small change to the
scheme so we'll edit the scheme that's in use. For large production systems
you would want to test your changes on a copy first.
Remember, any changes you make to a system default scheme will apply to
all the projects that currently use it and all new projects that are created.
a. Log in as the JIRA administrator Dakota Jones (djones/Charlie!) and

navigate to the Notifications schemes JIRA administration page. Note
that is the default notification scheme and is the only one for this
instance and both existing projects are using it.
b. Copy the Default Notification Scheme.
c. Edit the Copy of Default Notification Scheme.
d. Rename it to Original Default Notification Scheme – DO NOT
CHANGE. Add a description - For reference purposes only - do not
update. Now we can comfortably update the default scheme knowing
we have a copy.
2. Edit a default scheme:

a. Edit the Default Notification Scheme.
b. Remove Reporter from the Issue Comment Edited notification and the
Issue Moved notification.
c. Navigate to the Payroll project's Notifications administration page and
confirm the changes show there.
d. Navigate to the Human Resources Notifications administration page
and confirm the changes show there.
Be careful when editing default schemes. You only want to change

defaults if it's a change that should be shared among all projects
currently using the default and all projects that will be created in the
future.

Sometimes when you make a change, even if everyone seems to want it,
once it's in place you may get complaints and need to change it back.
Getting all the stakeholders involved beforehand will minimize this but
occasionally even the best thought out change may need to be reverted.
How would you revert back to your original default notification scheme
for the current projects and all new projects?
Answer: You can associate current projects to your backup (original)

notification scheme but new projects will always be created with the
Default Notification Scheme (the original one that you edited). You
cannot change the default notification scheme to another scheme. So to
revert back you use the backup as a reference to undo your changes.
Many Teams In Space users are complaining of too many JIRA notification emails.
Most of the stakeholders have agreed that users who report issues don't want to be
sent notifications on so many events. They've requested to stop Reporters from
getting notifications when a comment is edited on an issue and when an issue is
moved.
1. Backup a default scheme:
Before editing a widely used scheme and especially a system default

scheme, you should save a copy in case you make mistakes or the changes
turn out to be unpopular. Then you can use that as a reference if you need to
undo your changes. In this case you're only making a small change to the
scheme so we'll edit the scheme that's in use. For large production systems
you would want to test your changes on a copy first.
Remember, any changes you make to a system default scheme will apply to
all the projects that currently use it and all new projects that are created.
a. Log in as the JIRA administrator Dakota Jones (djones/Charlie!).

b. Navigate to the Notifications schemes JIRA administration page. Note
that is the default notification scheme and is the only one for this
instance and both existing projects are using it.
c. Click Copy.

d. Click Edit for the Copy of Default Notification Scheme.
e. Now we'll rename the copy to make it clear it's a backup of the original:
i. Name: Original Default Notification Scheme – DO NOT
CHANGE
ii. Description: For reference purposes only - do not update
iii. Click Update.
f. Now we can comfortably update the default scheme knowing we have a

copy.
2. Edit a default scheme:

a. Click the name, Default Notification Scheme, to edit the notifications.
b. Scroll down to the Issue Comment Edited notification and click Delete
next to Reporter. Click Delete to confirm.

c. Repeat this step to remove Reporter from the Issue Moved notification.
d. Navigate to the Payroll project's Notifications administration page and

confirm the changes show there.
e. Navigate to the Human Resources Notifications administration page

and confirm the changes show there.
Be careful when editing default schemes. You only want to change

defaults if it's a change that should be shared among all projects
currently using the default and all projects that will be created in the
future.
Sometimes when you make a change, even if everyone seems to want it,
once it's in place you may get complaints and need to change it back.
Getting all the stakeholders involved beforehand will minimize this but
occasionally even the best thought out change may need to be reverted.
How would you revert back to your original default notification scheme
for the current projects and all new projects?

Answer: You can associate current projects to your backup (original)
notification scheme but new projects will always be created with the
Default Notification Scheme (the original one that you edited). You
cannot change the default notification scheme to another scheme. So to
revert back you use the backup as a reference to undo your changes.
Optional Exercise 4 – Deleting a Project & Sharing a Scheme

the next page.
1. Delete a project and see what happens to its schemes:

Sometimes you will want to create a test project to experiment with
configurations. Once you're done you may want to delete it. Or you may
have made a mistake when creating a project so need to delete it and start
over. Let's see what happens to the schemes that are created for a deleted
project.
a. As Dakota, create a new Software project using the Basic software

development template. Do not select to create with shared
configuration. Call it Test.
b. Navigate to the new project's Summary administration page.
Which schemes were created specifically for this project and which
schemes are the default schemes shared with other projects? How do
you tell them apart?
Answer: The schemes created specifically for this project are for issue
types, workflows, screens, and issue type screens. These all have the
project key in the name, for example, TEST: Software Simplified
Workflow Scheme. The default schemes shared with other projects are
for permissions, notifications, and field configuration and start with the
word Default.
Note the permission scheme this project is using – Default software

scheme. Software projects, by default, use the Default software scheme
and not the Default Permission Scheme that Business projects use.
c. Navigate to the Projects JIRA administration page and delete your new
project.
d. Navigate to the Workflow schemes administration page.
Do you see your deleted project's workflow scheme there?

Answer: Yes, it's still there but it's now listed in the Inactive section (you
need to expand this).
When you delete a project all schemes for that project remain, they are
not deleted.
Why aren't a project's schemes deleted when you delete the project?
Answer: Because they may be shared with other projects or you may
want to reuse them for another project.
2. Share a scheme between projects:

Human Resources need to create a new Onboarding project. They want to
customize many things so they decided to create it from the default template
rather than sharing a project configuration. But the JIRA administrator sees
that their permissions requirements are identical to the one used by HR and
Payroll so the new project will share just that one scheme.
a. Create a new Business - Project management project called
Onboarding. Don't create it with shared configuration.
b. Navigate to the Onboarding Permissions administration page. It's
currently using the Default Permission Scheme.
c. Use a different scheme by selecting then associating the HR Permission
Scheme.
d. Click the SHARED BY 3 PROJECTS link to see which projects now
share this scheme and will be affected by any changes to this scheme.
Instead of sharing a scheme, if you want to use another project's scheme

as a starting point and then customize it, you would instead copy the
scheme then associate it with the project. That saves you some
customization work but you could end up with a lot of schemes to
maintain. Generally you want to share schemes as much as you can
especially between similar projects, for example, all Marketing projects.
Congratulations on completing the last lab!
1. Delete a project and see what happens to its schemes:
Sometimes you will want to create a test project to experiment with
configurations. Once you're done you may want to delete it. Or you may
have made a mistake when creating a project so need to delete it and start
over. Let's see what happens to the schemes that are created for a deleted
project.
a. As Dakota, create a new project:

i. Type: Software – Basic software development
ii. Do not select to create with shared configuration.
iii. Click Next then Select.

iv. Give it a name of your choosing, for example, Test. Click Submit.
b. Navigate to the new project's Summary administration page.
Which schemes were created specifically for this project and which
schemes are the default schemes shared with other projects? How do
you tell them apart?
Answer: The schemes created specifically for this project are for issue
types, workflows, screens, and issue type screens. These all have the
project key in the name, for example, TEST: Software Simplified
Workflow Scheme. The default schemes shared with other projects are
for permissions, notifications, and field configuration and start with the
word Default.
Note the permission scheme this project is using – Default software

scheme. Software projects, by default, use the Default software scheme
and not the Default Permission Scheme that Business projects use.

c. Navigate to the Projects JIRA administration page.
d. In your new project's row, click Delete.
e. Note the warning – deleting a project can’t be undone! Click Delete to

confirm.
f. Click Acknowledge once the deletion is complete.

g. Navigate to the Workflow schemes administration page.
Do you see your deleted project's workflow scheme there?
Answer: Yes, it's still there but it's now listed in the Inactive section (you
need to expand this).
When you delete a project all schemes for that project remain, they are
not deleted.
Why aren't a project's schemes deleted when you delete the project?
Answer: Because they may be shared with other projects or you may
want to reuse them for another project.
2. Share a scheme between projects:

Human Resources need to create a new Onboarding project. They want to
customize many things so they decided to create it from the default template
rather than sharing a project configuration. But the JIRA administrator sees
that their permissions requirements are identical to the one used by HR and
Payroll so the new project will share just that one scheme.
a. Create a new Business - Project management project called
Onboarding. Don't create it with shared configuration.
b. Navigate to the Onboarding Permissions administration page. It's
currently using the Default Permission Scheme.

c. Click Actions then select Use a different scheme.
d. Select the HR Permission Scheme and click Associate.
e. Click the SHARED BY 3 PROJECTS link to see which projects now

share this scheme and will be affected by any changes to this scheme.
Instead of sharing a scheme, if you want to use another project's scheme

as a starting point and then customize it, you would instead copy the
scheme then associate it with the project. That saves you some
customization work but you could end up with a lot of schemes to
maintain. Generally you want to share schemes as much as you can
especially between similar projects, for example, all Marketing projects.
Congratulations on completing the last lab!

Lab 7 Appendix
Best Practices
Having many I've created new schemes for Generally you want to avoid
schemes incurs each of my new projects. But having too many schemes as
administrative it's a lot of work to create all that could require a lot of work
overhead and these schemes and keep to maintain them. You want to
possible them all maintained. And I've share schemes as much as
performance noticed performance is not possible where you have a
degradation. as good as it was. reasonable belief that the
shared configuration will stay in
sync. Even if things go out of
sync, most schemes can be
easily copied and reverted if
necessary. Consider sharing
schemes for different project
types or Departments. For
example, Development may
have a set of schemes that are
shared for all Development
projects
Can't easily roll I updated the Default Before editing a widely used
back changes if Notification scheme and scheme and especially a
you make a made a lot of changes based system default scheme, you
mistake updating a on some users requests. should save a copy in case you
widely used However now company make mistakes or the changes
scheme or if policy has changed so I need turn out to be unpopular. Then
requirements to change them back but I you can use that as a reference
change. don't have a copy of the if you need to undo your
original Default Notification changes. For large production
Scheme and I can't systems you would want to test
remember how it was set up your changes on a copy first.
originally! Remember, any changes you
make to a system default
scheme will apply to all the
projects that currently use it
and all new projects that are
created

JIRA-Admin-Pt1-Lab Workbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JIRA-Admin-Pt1-Lab Workbook

Uploaded by

Copyright:

Available Formats

JIRA Administration Part 1:

Getting up and running

Lab access and login instructions follow:

Mitch Davis Username – mdavis

JIRA Administration Part 1 – Lab Workbook 1

Exercise 1 – Verifying Applications & Configuring Integrations

2. Access the JIRA Administration pages:

2 JIRA Administration Part 1 – Lab Workbook

b. You may see a message recommending you perform a re-index. This

Do not upgrade or install new versions! The versions that this

What applications are installed and licensed?

When does your maintenance expire for JIRA Service Desk?

Answer: View the date next to Maintenance expires.

JIRA Administration Part 1 – Lab Workbook 3

For production installations, set up JIRA and Confluence on separate

j. Edit the Confluence application link:

5. Verify Confluence integration:

4 JIRA Administration Part 1 – Lab Workbook

b. Navigate to the Application Navigator administration page.

7. To start the next exercise, go to page 18.

JIRA Administration Part 1 – Lab Workbook 5

1. Download your lab resource files and log in to JIRA:

c. You see the default System Dashboard.

2. Access the JIRA Administration pages:

6 JIRA Administration Part 1 – Lab Workbook

b. You may see a message recommending you perform a re-index. This

JIRA Administration Part 1 – Lab Workbook 7

ii. On the Indexing administration page in the Re-Indexing section,

iii. Once the re-indexing is complete click Acknowledge.

8 JIRA Administration Part 1 – Lab Workbook

Do not upgrade or install new versions! The versions that this

What applications are installed and licensed?

JIRA Administration Part 1 – Lab Workbook 9

When does your maintenance expire for JIRA Service Desk?

Answer: View the date next to Maintenance expires.

4. Integrate Confluence with JIRA:

Either type . (period) then Application links or in the Applications

e. Click Create new link.

10 JIRA Administration Part 1 – Lab Workbook

JIRA Administration Part 1 – Lab Workbook 11

j. There's one more step you need to do because in our training

For production installations, set up JIRA and Confluence on separate

12 JIRA Administration Part 1 – Lab Workbook

l. Click Outgoing Authentication, select the OAuth tab then check

m. Click Incoming Authentication and if a dialog pops up asking you to

JIRA Administration Part 1 – Lab Workbook 13

5. Verify Confluence integration:

a. Click the application navigator icon and select Confluence.

b. This takes you to Confluence.

d. Navigate to the Application Navigator administration page (under

14 JIRA Administration Part 1 – Lab Workbook

c. You can view add-ons in different ways. By default it shows user-

JIRA Administration Part 1 – Lab Workbook 15

16 JIRA Administration Part 1 – Lab Workbook

h. Close the dialog.

JIRA Administration Part 1 – Lab Workbook 17

Exercise 2 – Configuring the User Interface

1. Configure the look and feel of your JIRA instance:

18 JIRA Administration Part 1 – Lab Workbook

2. Customize the default dashboard:

Who will see this Dashboard?

3. To start the next exercise, go to page 23.

JIRA Administration Part 1 – Lab Workbook 19

20 JIRA Administration Part 1 – Lab Workbook