Jira-Admin-Pt1-Cloud-SG-APR272020.pdf

1 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

You are here to learn the basics of Jira administration! You'll also learn about site
administration.

You should know the basics of using Jira and have a basic understanding of projects,
issues, issue types, and workflow.

Schedule for the course.

Schedule for the course.

Here you see a list of all the modules in this course.
The next module is an introduction to Cloud administration.
The following two modules - Setting Up Your Site and Managing Site Users & Their
Product Access cover the tasks for site administration.
The rest of the modules in the course cover Jira administration. The last five modules
cover project administration (which can be performed by either Jira administrators or
project administrators).

In this module you'll get an introduction to Cloud administration.

Here you'll learn what Atlassian cloud organizations, cloud sites, and cloud products are.
You'll also learn about the different Atlassian cloud administration roles.

The Atlassian cloud is made up of sites which contain your users and what products they
use. And at the highest level there's the organization.
Atlassian cloud administration consists of three different levels of administration. The
organization administrator operates at the organization level, the site administrator
operates at the site level, and the product administrator operates at the product level.
Here's you'll learn site administration and product administration. Organization
administration is beyond the scope of this course. Let's get started!

An Atlassian cloud site contains a single instance of each Atlassian product you're using
e.g. Jira Software, Jira Service Desk, Confluence, Opsgenie, etc.
In this example, Acme global has two sites. The acme.atlassian.net site has Jira Software,
Jira Service Desk, and Confluence. The acme-eu.atlassian.net site has Jira Software and
Confluence. Each cloud site is a sub-domain of atlassian.net. Subdomains must be
globally unique.

The site administrator can add new products, upgrade products and remove any
products on their site as needed. They also manage their site users and groups here. We'll
cover inviting users to a site in a later module. And they manage who can access to the
products on their site.
In this example, Acme global has two sites. The acme.atlassian.net site has Jira Software
with 3 users who have access to that product, Jira Service Desk with 4 users, and
Confluence with 5 users. The acme-eu.atlassian.net site has Jira Software with 3 users
who can access that product and Confluence with the same 3 users.

The main responsibility for a product administrator is to administer Atlassian product
settings. For example, for Jira (containing Jira Software and/or Jira Service Desk) and/or
Confluence.
Each product also has other types of administrators. For example, project administrators
in Jira and space administrators in Confluence. These administrators manage parts of the
product, not the global product settings.

An Atlassian Cloud organization gives the organization administrator an overview of the
sites and products they have in use across their organization.
Organization administrators can also:
• Verify domains for their organization e.g. acme.com. Once you verify a domain, all the
Atlassian accounts that use email addresses from that domain become managed
accounts of the organization.
• Manage user accounts - edit, deactivate and delete, etc.
• Set up password policies and, if they have Atlassian Access, set up Security for their
organization, single-sign on, etc. This is a separate subscription you can buy for your
whole company.
• Configure site settings such as add other organization administrators.
We don't go into the details of administering an organization in this course. For more
information, see
https://confluence.atlassian.com/display/Cloud/Set+up+an+Atlassian+organization.
Supplemental information:
Atlassian Access provides:
• SAML single sign-on, password management, and two-step verification
• Audit log - track user, group, and product access activities.
• Set up user provisioning from an external directory using Atlassian Access. Note, if you
manage your users through G Suite, you'll do that at the site level. More on this later.

The three cloud administrators can access their administration tools from different URLs.
Organization administrators manage their organization and site administrators manage
their sites at admin.atlassian.com.
Product administrators go directly to their sites, for example, mysite.atlassian.net.
If you're an organization or site administrator, you can also go directly to the site and
access your respective administration pages through the menus.

Answer is on the next slide.

Answer: c An organization may contain multiple sites.
An organization admin can perform administrative tasks at all levels - organization, site
and product.
There can be only one instance of each Atlassian product in each site.
Product settings are configured at the product level.

In this module we'll cover setting up your cloud site.

Here you'll learn how to manage the products on your site, how to configure access to
your site, and how to set the landing product.
We'll cover user management in the next module.

This and the next module cover the tasks for site administration.
The rest of the modules in the course cover Jira administration. The last five modules
cover project administration (which can be performed by either Jira administrators or
project administrators).

When you set up a new site here are the main steps you need to perform as a site
administrator:
1. First you set up site product subscriptions. You choose which products you want and
how many users, etc.
2. Configure who can access the site
3. Set site settings such as which product users see first, links to applications, etc.
4. Configure who can access your products
5. Set up your groups
6. Set up product administrators e.g. Jira and Confluence administrators
7. Finally you can invite users to your new site
Steps 1 to 3 are covered in this module. The rest of the steps are covered in the next
module.

To administer a site, you need to be either an organization administrator or a site
administrator.
Now let's cover the tasks for site administration in more detail…

As a site administrator you can go to admin.atlassian.com to view and access all the
sites you have. From here you can directly access site administration pages to manage
users and groups, view your site bill, and grant product access.

Once you're on your site you can view all the administration pages for a single site. Here
we're looking at the Discover new products page where you can add new products to
your site.

You can keep track of your product subscriptions in site administration. You can search
for and add more products at any time. As well as upgrade and delete products you
already have.
You can see active user counts and billing information. Note that each user who joins
your site and is given access to your product(s), counts towards your products
subscription. In this example we see that We have a subscription for Jira Software for 10
users and 5 of those 10 licenses are used. You can also view billing details.

Now let's look at site access settings.

As a site administrator, you need to add users to your site. Even if you have managed
users at the organization level, they are not automatically added to your site.
You can manage various site access settings including whether users can invite others,
enable invitation links, who can join your site, and whether to be notified when a new
user gets access to the site. We'll cover these in detail next.

In site administration, if you select 'Existing users can send invitations to anyone', then
users will be able to enter email addresses to invite others to your site. For example, Jira
project administrators (and Jira administrators) could invite other users from their
projects and new Confluence users can invite others in their team when they first log into
Confluence. By default, users cannot invite others.
Allowing others to invite users reduces your administrative work of inviting users to your
site. But this should be weighed against how many users you want on your site and your
subscription limits.

In site administration you can enable invitation links for each product you have installed
on your site. You can enable these links at any time and share them with your
teammates so they can sign up to a specific product. This gives users who have Atlassian
accounts instant access to your site, without having to go through the invitation process.
If you turn it on for a particular product or products, links expire after 30 days and then a
new link is generated. If for any reason you want to render a link invalid, for example, if
you suspect it was sent out broadly to users who you don't want to access your site, you
can either turn it off or create a new link. This will make the original link invalid.
Enabling and sharing invitation links can be a great way to get users onboarded quickly.

You can control who can join your site in site administration under site access.
If you select Approve any domain then any user on any email address will be able to sign
up and access your site. You'd use this for a public site.
If you select Approve the following domains, you can manually define which domains are
approved. Users in these approved domains can join your site without an invitation or
administrator approval. In this example, we have approved the atlassian.university
domain.
If you select Don't approve any domain, all users will be forced to request access or be
invited.
With the 'Notify all site admins when a new user joins with an approved domain'
checkbox, you can also choose whether site admins should receive an email when a new
account gets access.
For more information, see
https://confluence.atlassian.com/display/Cloud/Site+access+settings+improvements.


Answer: False. Site administrators can always invite users to their site. However, if the
site administrator checks the "'Existing users can send invitations to anyone" checkbox
under the User invites tab, other users, for example, project administrators in Jira can
also invite users.


Answer: b and c.
If you approve the acme.com domain in site administration, you can still invite users from
other domains but only users from acme.com can self signup to your site.

Let's look at some additional site configuration.

As a site administrator, you can choose the product that your users see first when they
log in to your site. We refer to this as your site's landing product. For example, if you have
both Confluence and Jira on your site, you can choose either one to be the default
product users go to when they log in. You do this through the Product access page. Note
that it may take up to two hours to take effect after you change this setting.

Now let's cover some information that will help prepare you for doing the labs.

An Atlassian account is an online profile or identity that exists independently of the
Atlassian cloud sites or products used. Every Atlassian account is tied to an email
address. In this example, it's lucy@acme.com.
You as a user may have access to many Atlassian cloud products (even on different cloud
sites) but you use the one Atlassian account to log into all these sites. You can't combine
Atlassian accounts.
If you don't have an Atlassian account you can create one at id.atlassian.com.

At id.atlassian.com you can see all the products you have access to (and what cloud sites
they're on). You can simply click a product to go there. In this example Lucy has access to
Confluence, Jira Software, and Jira Service Desk on the univ-2 site and to Confluence and
Jira Service Desk on univ-3 site.
You can also see your recent work. In this example, Lucy sees two pages she recently
published in the Onboarding space in Confluence and a task she created in the Human
Resources Jira project.
id.atlassian.com is like a bookmark of all your Atlassian cloud products and work.
https://confluence.atlassian.com/display/Cloud/Your+Atlassian+account.

A single browser can only handle one Atlassian account. This is because browsers keep
cookies. Once you're logged into a cloud site on one browser, it remembers that login. So
if you open a new tab, you can't login as someone else. You can get around this by using
incognito or private windows in the browser.
In the labs you'll need to log in as different users. To avoid logging in and out a lot you
can either use different browsers or use an incognito/private window in the same
browser. You can open either an incognito window (Firefox) or private window (Chrome)
from the browser menu. Other browsers also have the same functionality.

What are the takeaways?
Site administration is where you manage your subscriptions, control your site users, and
anything else relating to the site as a whole such as setting your site's landing product,
etc.
Allowing others to invite users reduces your administrative work of inviting users to your
site. But this should be weighed against how many users you want on your site and your
subscription limits.
Enabling and sharing invitation URLS to specific products on your site gets users
onboarded quickly without having to go through the invitation process.

Instructor demo

In this module we'll cover managing site users and their product access.

This is the last module for site administration.
The rest of the modules in the course cover Jira administration.

We covered the first three steps in the last module. Here we'll cover:
• Configuring product access
• Setting up your groups
• Setting up your product administrators
• Inviting users to your site

Let's get started.

First let's look at setting up product access.

Users are the people who access Atlassian products. In this example, Alex, Dakota, Ravi,
Arianna, and Nikolas are all users.
A group is a convenient way to manage a collection of users. Users can belong to many
groups. In this example, Dakota belongs to both the IT and jira-administrators groups.
Alex belongs to the IT group and Ravi, Arianna, and Nikolas belong to the Marketing
group.
Use groups wherever possible to manage users rather than individual users to lessen
your administrative load.

To manage users and groups, you need to be either an organization administrator or a
site administrator.

Groups are one way of determining what users can do in Atlassian cloud. There are a
number of groups that are already set up for you. Being members of these groups can let
users do different things - give them access to products, control what they can do within
products and give them administrator privileges. For example, being in the jira-
administrators group lets you configure Jira settings.

Here are the administrator groups you'll see by default. You'll always have the site-
admins group on your site. This group is for the user(s) that administer site settings. If
you've subscribed to Jira, you also have the administrators and jira-administrators
groups.
• The administrators group is for the user(s) who administer both Jira and Confluence.
This group also gives the user(s) access to the Jira and Confluence products, so they'll
count towards your subscription.
• The jira-administrators group is for the user(s) who administer Jira. However, this
group doesn't give you access to the Jira products, so they don't count towards your
subscription. Without product access they cannot see project content such as issues.
Some sites may want to restrict Jira administrators. If you want them to see content,
add them to a group that has access. Then they'll count towards your subscription.
The is no confluence-administrators default group. If you have users who you want to be
Confluence administrators but not consume a Jira license (by being in the administrators
group), create a separate group and give that group the 'Confluence Administrator' global
permission.

What groups you have on a new site depends on the products you subscribed to. Each
Atlassian product has a group associated with it that provides access to the features of
that product. If a user is given access to a product, they will automatically be placed in
the default access group for that product. The default access groups are:
• jira-software-users for Jira Software
• jira-servicedesk-users for Jira Service Desk
• jira-core-users for Jira Core
• confluence-users for Confluence
• opsgenie-users for Opsgenie
When you subscribe to Jira Software or Jira Service Desk you automatically get all the
features of Jira Core, but you don't see the jira-core-users group. This group is only
created if you explicitly subscribe to Jira Core. For example, if that is the only Jira product
you subscribed to.
For more information about default groups, see
http://go.atlassian.com/cloudmanagegps.

Out-of-the-box, the default access groups are set up for each product. For example, on
the Product access page in site administration you see the jira-software-users group is
the default access group for Jira Software. If you add a user to Jira Software, they will
automatically be placed in this group. You can use your own group to provide access to
your products. You don't have to use the out-of-the-box groups, they are provided for
your convenience. You can also set up more than one default access group for each
product.

On the Product access page, you control which groups have access to which products.
You can have multiple groups for a product. Out-of-the-box, groups are set up for each
product. For example, here you see the administrators, jira-software-users and site-
admins groups are set up to provide access to Jira Software. If a user is a member of any
one of these groups they will have access to Jira Software. If a user is a member of more
than one of those groups, they will only consume one license for that product. You can
add and delete groups here but you can't assign individual users to products.

On the Product access page, you can also specify which products new users will get
access to automatically. Here you can see that new users will have access to Jira
Software. When a site administrator invites users those products are selected by default
but the administrator can select or deselect products as they wish. But there are
situations where users are assigned product access automatically. For example, you
have a public site where users can enter bugs. Or when a user is sent an invite URL
(generated from site access page). In this example, when users self signup they
automatically get access to Jira Software (and they'll be added to the default access
group for Jira Software, jira-software-users).

Here's another product access example.
You can assign the same group to multiple products. You may wish to do this to ensure
members of this group always have full product access. In this example, the site
administrator has assigned the Developers group to both Jira Software and Confluence.
Note, the site-admins group and the administrators group have access to all products.
Care should be taken when assigning a group to multiple products, as the group
members will consume a license for each product (unless they’re already in a group
assigned to that product). The exception is Jira Core, a user with access to any other
product automatically has access to Jira Core, so they will not consume a license for Jira
Core if they belong to a group associated with another product.

See the next slide for the answer.

Answer c. A self-signup user would have access to both Jira Software and Jira Service
Desk.
1. A self-signup user would automatically be given access to Jira software because
'New users have access to this product' is enabled.
2. New users added to Jira Software will be placed in the default access groups - jira-
software-users and Development.
3. Development is also a product access group for Jira Service Desk.
Care should be taken when assigning a group, that's a default access group for one
product, to multiple products. Unless that's what you specifically want to do.

The answer is on the next slide.

Answer: a and c. b is not correct because you can select more than one default group for
each product.

Now let's look at how to add users to your site.

There are a number of ways you can bring users into your site:
1. You can enable self signup. In site access you can specify that users from a specific
domain or domains can self signup or that anyone can self signup (public site). In this
case users join the site themselves using their Atlassian accounts. We covered this
earlier.
2. Integrate a G Suite user directory. We won't go into the details of G Suite integration
in this course.
3. Send them an email invitation to join the site. More on this in the next slides.
4. Users request access. More on this in the next slides.
For more information on G Suite, see
https://confluence.atlassian.com/display/Cloud/G+Suite+integration.

You can invite users to your site through site administration. You specify their email
address and what role they'll have (more on this on the next slide). You also select which
product(s) they’ll be using. The user will automatically be added to the default group(s)
associated with the product(s). And you can optionally specify additional group
memberships.
Once users are created, they count towards billing even if they don't accept the invite or
ever login.
If a user you invite doesn't have an Atlassian account, they'll be walked through the
Atlassian account signup process.
For more information on inviting users, see http://go.atlassian.com/cloudinviteusers.
For more information on licensing, see atlassian.com/licensing/cloud.

When you invite a user, you assign them one of three roles.
The Basic role gives the user access only to the products you specify.
The Trusted role gives the user access to all products on your site. But they do not
become members of any of the administrator groups. It's like a subset of the
administrators group permissions. They can administer products on the site. But when
they go to site administration, they only get access to the Invite users screen. It's a
limited screen - they can only enter email addresses and what products the users should
access. Users are added with Basic access. The only other thing they can do at the site
level is to discover new Atlassian products.
The site administrator role gives the user the ability to administer the site, determine
user access, and update billing details. They will be in the site-admins group.

If someone comes to a product page on your site they can't access (e.g. another user
sends them the URL), they'll see a Request access button. A user can also request access
for other users to get them collaborating in the product.
Whenever a user requests access, all requests appear on the Access requests page in site
administration, where you can grant or deny the request.

From site administration you can revoke site access for a user or remove a user:
• Revoke site access for a user if you don't want them to be able to use your site at least
temporarily. They won't have access to any products. They will still be listed in the
Users for your site and you can give them access at any time. They won't count
towards your licensed users. You might do this, for example, if you have a contractor
that works for you at the end of every quarter. You can revoke site access when they
leave and reinstate it when they return. In this example, Max Taylor had access to Jira
Service Desk and Jira Software however his access has been revoked. Note the grey X
next to Has access on site. If you click Has access on site again, he regains access and
automatically regains access to Jira Service Desk and Jira Software.
• Remove a user if you don't want them to appear on your site. Removing a user from
your site, doesn’t remove them from your organization or other sites you manage. A
removed user will no longer count towards your licensed users.

Apart from administrator groups, care should be taken when assigning a group to
multiple products. New users created and assigned product access are added to that
product's default group. If this group is also assigned to an additional product, the new
user will also gain access to the additional product.
Look out for invited users who never accept, they are still billable users.

Instructor demo

In this module we'll cover configuring Jira.

We've covered site administration. In this and the next module we cover Jira
administration at the global level.

Here you'll learn how to integrate other products with Jira, how to find new apps to add
to Jira, how to brand your user experience or look and feel and how to configure auditing.

First let's do an overview of Jira administration.

Jira is an issue tracking system that has been primarily used within the software
development field. But Jira is flexible enough to support other areas of focus outside of
software development. Many non-software development project teams use Jira for
tracking issues as well as Finance teams and more.
There are three products that make up the Jira Platform. These products match the three
main audiences. Each Jira product comes complete with a specific set of features and
functions, which tailors the experience delivered to its users.
Jira Software is designed for agile teams whose focus is software development. It
enables these teams to plan projects, manage dependencies and track team progress.
Jira Service Desk is designed for IT and service teams to implement service desks quickly
and to manage incidents, problems, changes, and service requests.
Jira Core is designed for business teams, whose goals are to keep their teams organized
by planning, tracking, and reporting on their business projects. It’s a lightweight version
of Jira Software, stripping away all unnecessary features for Business teams e.g. sprint
planning. If you have Jira Software or Jira Service Desk you automatically get all the
functionality of Jira Core, you don't need a separate subscription.

Jira administrators access Jira administration from the product through Settings (the cog
icon) in the menu.

There are many ways to configure Jira. These are the top tasks and are the ones covered
in the rest of this module.
Global permissions and project configuration are also very important tasks to configure
your Jira. These will be covered in later modules.

Now let's look at integrating products and apps into Jira.

If you use Jira Cloud, most products that are part of your Cloud subscription, such as
Confluence Cloud or Opsgenie, are linked together automatically.
You can connect your Jira Cloud instance to Bitbucket Cloud so that Jira issues
automatically update to show recent branch, commit, pull request activity, builds, and
deployments. You do need to connect these yourself. See the notes for resources.
If your company uses Atlassian server products in conjunction with your Atlassian Cloud
site, you can create two-way links between your cloud and server products using
Application Links. For example, you can link Jira Cloud to Confluence Server. Then you can
include shortcuts to Confluence page links when creating or editing a Jira issue. Linking
Jira to other Atlassian products allows you to include information from those products
directly in Jira projects and issues. You can also link Jira Software Cloud to your own
locally installed instances of the Atlassian development tools such as Bitbucket and
Bamboo Server.
For the steps to connect Jira Cloud to Bitbucket Cloud, see
https://confluence.atlassian.com/display/
AdminJIRACloud/Connect+Jira+Cloud+to+Bitbucket+Cloud. For more information on
integrating with development tools, see https://confluence.atlassian.com/display/
AdminJIRACloud/Integrating+with+development+tools.

Here's an example of linking Jira Cloud to Confluence Server using Application Links
(sometimes called "app links"). On the Configure Application Links page you simply enter
the URL for Confluence Server and create a new link. Now you can link Jira issues to
Confluence Server pages.
To set up application links between cloud and server products, you must have
administrator permissions on both the cloud and server products.
You should also make sure you meet the following requirements:
• The product must be accessible via the ports specified in the Compare Atlassian cloud
vs server page.
• Check that the Base URL for the server product is set correctly.
• If you want to use SSL, you need to use a valid certificate (not a self-signed certificate).
• Your server needs to be reachable by the Atlassian Cloud IP range.
• The URL for the product must fulfill the RFC 1738 URL standards.
https://confluence.atlassian.com/display/Cloud/Link+to+server+products+from+Cloud and
http://go.atlassian.com/cloudapplinks.

An app (sometimes called an add-on or a plugin) is an installable component that
enhances the functionality of Jira Cloud in some way. Jira comes with many pre-installed
apps (called system apps). You can install more apps by downloading an app from the
Atlassian Marketplace (from Atlassian or third-party vendors).
Governance is important. For example, you install an app for extended JQL functionality.
Then you disable it because system has grown, more people are using it and there’s a
performance hit. But users have used the JQL extensions and now all custom JQL will be
invalid. Users aren’t happy. Before you install an app, ensure there’s a business
requirement for it, don’t just install any app.
https://confluence.atlassian.com/display/AdminJIRACloud/Managing+apps.
When you install or update an app, Jira will automatically grant the app the correct
permissions for its scope through the atlassian-addons-project-access role. It will also
check the permissions of existing add-ons across all Jira and Jira Service Desk projects,
and grant them the correct permissions as well. We'll discuss permissions and roles later
in the course. For more information, see https://confluence.atlassian.com/
servicedeskcloud/blog/2017/02/add-on-permissions-update.
You can also connect to GitHub. See
https://confluence.atlassian.com/display/AdminJIRACloud/Connect+Jira+Cloud+to+GitHub


Answer: You can integrate all of these products with Jira cloud. If Confluence Cloud is on
the same site, it will be integrated automatically.

Now let's look at how to configure the user experience.

On the Look and Feel page you configure your branding. For example you can upload or
link to your company’s logo. You can also update the color of the menu. In this example,
we've changed it to dark grey. Ensure you keep accessibility in mind when changing the
colors, especially the contrast between the sidebar and the text/icon colors. The Title is
the name of the product, by default Jira. In this example, we've changed it to TIS Jira.
You can also upload or link to your own Favicon which typically appears to the left of
your browser’s URL field and on browser tabs displaying a page on your Jira site. It must
be a png.
Date/Time format allows you to customize the way dates and times are presented to
users in Jira.
Go to https://webaim.org/resources/contrastchecker/ to check you're meeting
accessibility standards.
Go to design.atlassian.com for principles, guidelines and assets for designing and
building awesome Atlassian experiences.

Most user-visible pages in Jira are internationalized and can be viewed in many different
languages.
When you install Jira, a number of languages are installed, and you can choose the
default on the General configuration page.
What language a user sees in Jira depends on three settings. These are, in order of
precedence:
1. If the user has updated the language in their profile settings (Avatar > Account
settings > Account preferences), this takes precedence.
2. The user's browser language setting.
3. If Jira can't detect the browser's language, it will use the Default language setting in
Jira.
For a complete list of all the languages available, see
https://confluence.atlassian.com/display/Cloud/Languages.

Finally let's look at a few other configurations.

Jira's time tracking feature enables users to record the time they spend working on
issues. A Jira administrator can configure time tracking settings.
Configure time tracking settings by editing the following fields:
• 'Working hours per day' — enter a value (e.g. 8). Decimals are accepted.
• 'Working days per week' — enter a value (e.g. 5). Decimals are accepted.
• 'Time display format' — select pretty/days/hours. This will determine the format of
the 'Time Spent' field when an issue is displayed.
• 'Default unit for time tracking' — select minutes/hours/days/weeks. This will be
applied whenever your users log work on an issue without specifying a unit.
• 'Copying of comments to work description' — When enabled, comments added when
transitioning an issue will be copied to the Work Description. User time log entries
will only be visible to members of the project role or group selected. Disabling this
option will make user time log entries visible to anyone by default.
You can also change the time tracking provider to provide advanced functionality. You
can find custom time tracking providers on the Atlassian Marketplace.
For more information, see http://go.atlassian.com/cloudtimetrack.

The auditing feature tracks key activities in Jira products. These activities are recorded in
an audit log that can be viewed on the Audit Log page. This can be a handy tool in
helping you diagnose problems in Jira products or used for security purposes. Here you
can see that Dakota Jones created and updated workflows and updated the Human
Resources project details and schemes.
The following information is audited by Jira products:
• project changes
• permission changes
• workflow changes
• notification scheme changes
• screen changes
• custom field changes
The audit log is not intended to record all activity in Jira products. For example, it doesn't
track issue updates or pages that are viewed by a user. Rather, the audit log is intended
to record configuration changes that can impact users and projects.

You can change the retention period for activities recorded in the audit log. Here we've
changed it to 6 months If you modify the audit log retention period, ensure you follow
your company’s retention policies!
You can also configure the audit log to not include events triggered from your external
repository.
For more information, see http://go.atlassian.com/cloudauditing.


Answer: b and d
You can find configuration change information in the audit log such as project, workflow,
screen, permission changes, etc. But it doesn't track issue updates or pages that are
viewed by the user.

Integrate other products with Jira to share information between products.
Apps can be valuable to enhance the functionality of Jira. But before you install an app,
ensure there’s a business requirement for it, don’t just install any app.
View the audit logs when there’s a problem after configuration changes. This will let you
see who made the change and details of the change.
Follow your company’s retention policies for the audit log so you don't lose important
information.

Instructor demo

In this module we'll cover configuring global permissions.

This is the second and last Jira administration module at the global level.

Here you'll learn about the global permissions and what each one does, and you'll learn
how to assign global permissions to and remove global permissions from groups.

Permissions are settings within Jira products that control what users within those
products can see and do. All Jira products allow a variety of permissions: from whether
users can administer projects to whether a user can see a specific type of comment on an
issue. These permissions can differ between products.
Permissions are different from product access, which is controlled by groups that have
Use access for a product.

Jira has both global permissions and project permissions.
Global permissions allow you to control functionality throughout Jira and are project
independent. For example, whether users can see the other users in the product. Global
permissions are granted to groups and can only be modified by Jira administrators.
Project specific permissions let you restrict project related functionality to individual
users, groups or project roles. For example, who can see and edit the project's issues.
Project specific permissions and project roles are covered later in the course.

Administer Jira lets users perform administrative functions throughout Jira.
Browse users and groups lets users view and select users or groups from the user picker,
and share issues. Users with this permission can see the names of all users and groups
on your site.
Share dashboards and filters lets users share dashboards and filters with other users.
Manage group filter subscriptions lets users create and delete group filter subscriptions.
For example, you create a search filter then you set up a subscription for an individual or
group. They get an email of the filter results as often as you set the timing. Be careful as
users could create SPAM by sending it to a wide audience often (even every 5 minutes).
Make bulk changes lets users modify a collection of issues at once. For example, resolve
multiple issues in one step. The bulk operations include Bulk Edit, Bulk Move, Bulk
Workflow Transition, Bulk Delete. Consider whether to grant this permission carefully. For
example, in a public site where anybody can sign up and create issues, a user with this
permission and the Add Comments project permission could comment on all accessible
issues. It's difficult to undo bulk changes like these.
Create next-gen projects lets users create next-gen projects that do not leverage or
affect the existing projects. A team could configure this project without a Jira
administrator. By default, any logged in user can create a next generation project.

Global permissions are granted to groups. In this example the Jira administrator assigns
the Browse users and groups global permission to the Developers group. Many people
think that these can be added to or further defined, but they can’t be.
You have to be a Jira administrator to grant global permissions.
For more on global permissions, see http://go.atlassian.com/cloudglobalperms.

The Administer Jira permission is unique in that even though it is shown on the global
permissions page, it is managed by providing a group access to Jira administration. In
this example, Dakota is added to the jira-administrators group. She then becomes a Jira
administrator and has the Administer Jira permission. Only site-admins can manage
groups in site administration.

These are the out-of-the-box global permissions that are assigned to the Jira default
groups.
The three administrators groups - jira-administrators, administrators, and site-
administrators have all the global permissions.
Users in the default product access groups have all five non-administration global
permissions by default.
Any logged in user can create next-gen projects regardless of whether they are in a
default access group or not.
Users with the Administer Jira permission can always create next-gen projects, even if
that group is removed from this permission.

You can assign global permissions to the Public group. This means anyone who has
access to your Jira. Be careful assigning global permissions to Public. If you have a public
site and grant permission to Public to Browse users and groups, user and group names
will be publicly available on the internet. Also, as shown here, if you give Public the
permission to make bulk changes, anonymous users who are not logged in to Jira can
make bulk changes for any issues they're permitted to view.
You can do this with all other global permissions, except Administer Jira, but these are
the two to watch out for.

Allowing users to create their own next-gen projects means less work for the Jira
administrator because they don't need to create every project. This gives power to the
users as they don't need to involve the Jira administrator. They can create and manage
their own projects. And they can create their own projects as soon as the need arises
without involving the Jira administrator. The potential downside is that users, especially
in a very large site, could create a huge number of projects. If the number is incredibly
high this could possibly create performance issues. Allowing users to create their own
next-gen projects is the default setting.
If you change the default setting and don't allow any users to create their own next-gen
projects it means more control but also more work. If only Jira administrators can create
next-gen projects that person or persons could become a bottleneck, with users waiting
for their projects to be created.
Alternatively the Jira administrator could give this permission to a group of chosen users,
for example, Team Leads. That way the Jira administrator can offload some work and
only some users will need to wait for projects to be created.
Note that only Jira administrators can create classic projects.

The answer is on the next slide

Answer: a True. If a user has the Bulk Change permission (plus the project permission to
delete issues) they could delete all the issues in a project.

Best Practices
Whatever group you grant the Browse users and groups global permission to can see
everyone's names, which is a consideration if Jira is accessible externally. Be especially
careful of granting this to 'Public'.
The decision to grant the Make bulk changes global permission should be considered
carefully. This permission grants users the ability to modify a collection of issues at once.

In this module we'll cover Jira projects at a high level.

We've covered site administration and Jira administration at the global level. For the
remainder of the course we are covering project administration.

In this module you'll learn the differences between classic and next-gen projects and
their different project templates.
You'll also review project concepts common to both classic and next-gen projects - issue
types, fields, workflow and project categories.
We'll go into the details of the different project types in later modules.

Jira Cloud comes with classic and next-gen projects.
Classic projects have a huge number of options for planning, tracking, and reporting on
your team's work. They're powerful and highly configurable.
Next-gen projects are fast to set up, easy to configure, and user-friendly.
Only Jira administrators can create classic projects, but any user can create next-gen
projects by default.
Also project configuration can be shared between classic projects. Whereas any changes
you make to a next-gen project won't affect other projects.
In the future Atlassian may introduce the ability to share configurations between next-
gen projects.
For a list of the differences between classic and next-gen projects, see
https://confluence.atlassian.com/display/JIRASOFTWARECLOUD/Working+with+next-
gen+software+projects. Also watch the video, https://youtu.be/5aBFgDi0KgE.

Each of the three Jira products is suited to different types of projects. Jira Software is
ideal for creating software projects. Jira Service Desk is ideal for any kind of Help Desk
application. Jira Core is ideal for any business application.
Depending on which Jira products you have, you may have more than one project type
available. The project types are Software (if you have Jira Software), Service Desk (if you
have Jira Service Desk) and Business (if you have Jira Software, Service Desk or just Jira
Core).
Each project type has a number of project templates available. Project templates are
sets of pre-configurations which are the default starting points.
• Software projects give you Kanban and Scrum templates. The Bug tracking template is
also available for classic projects.
• Service desk projects give you IT and internal service desk templates, among others.
• Business projects (classic only) give you Project management, Task tracking, Content
management, and more.
Once you create a project, users can go to work with the defaults or you can customize
them to suit your needs.
Going forward, we'll concentrate on Software and Business projects and won't go into
details of Service Desk projects.

All projects regardless of type contain users, issues and at least one workflow.
Team members or users manage and work on the work items in the project.
These work items are described in issues. Issues store data in fields. This data is
automatically gathered to provide reports on project status and metrics.
In a project there are different types of issues for managing things like bugs, tasks,
stories, etc.
Issues can have associated workflows, because different tasks have different processes
associated with them. Workflows are your business processes. A workflows defines the
sequence of steps that all issues of a particular issue type must go through to complete.
Jira projects are a way of grouping issues together and applying workflow and issue
types to them.

Jira enables you to keep track of different types of work items - bugs, tasks, etc. - by using
different issue types. When creating a project, project-specific issue types are established
by default depending on which project type and template is used. The Jira administrator
(classic) or the project administrator (next-gen) can add or edit Issue types as necessary
to support the team's business process and meet their needs.
Here you see some of the default issue types for Software and Business projects:
• Epic – A big user story that can contain other issues.
• Bug — A problem that impairs or prevents the functions of a product.
• Story – A requirement from the user's perspective.
• Task — Work that needs to be done
• Sub-task – A piece of work that is required for another issue. This is a child of
another issue.

Here we see an issue (bug) - which is simply a collection of fields. Fields are the data
entry/view/edit mechanism for issues.
Information for each issue is held in the fields that are associated with that issue. You
can tailor these fields to suit your organization's needs.

Here's an example content management workflow (one of the Business templates). Each
content item (e.g. article, course, etc.) could be stored in Jira as an issue and administered
in the workflow shown here.
A workflow is made up of statuses and transitions.
• Statuses represent the position of the issue in a workflow. An article can be identified
to do, in draft form, in review, approved, and published. Every status should be a
unique state in your workflow and describe what's already happened.
• Transitions are the way a particular issue moves from status to status. Articles are
submitted to review, rejected and sent back to be written again, approved, and
published.
Assignees are also important in workflow - workflows guide how people work together.
In Jira, the assignee dictates who's responsible for an issue. When books are in draft
form, the assignee is set to the writer. When the book is reviewed the assignee may be a
senior writer, and so on.

A board is a representation of the workflow. Each column represents a status in the
workflow. In this example the workflow has four statuses - TO DO, IN PROGRESS, QA,
AND DONE.
Moving an issue on the board, changes the value of its status and its position in the
workflow.

As a Jira administrator, you can create project categories so your team can view work
across related projects in one place. Your team can use categories in advanced search,
filters, reports, and more. Note that project categories cannot be used to create project
hierarchies (such as parent projects).A Jira project can only belong to one category. Jira
does not support sub-projects or parent projects, that is, you cannot nest projects.
In this example, there are two project categories - HR and App Dev. The HR category is
associated with two projects - Guidelines and People. And the App Dev category is
associated with three projects - Mars App, Star App, and Sun App.

Answers on next slide

Answer: d, a field is not a type of issue. Fields hold the information for an issue.
Bug, Story, Task, Epic are all issue types.

Issues are of different types so you can keep track of different types of work.
Issues have fields that hold the issue's information.
The process your issues go through is called workflow.
To view work across related projects use project categories.

This module covers creating and configuring classic projects.

This is the second module covering project administration.

In this module you'll learn how to create classic projects, update project workflow, edit
screens and add issue types to classic projects.
Throughout this module when we refer to projects, we mean classic projects unless
explicitly stated otherwise.

First let's look at creating classic projects.

Classic projects have a huge number of options for planning, tracking, and reporting on
your team's work. They have schemes, workflows, reports, version management, and so
on.
They're powerful and highly configurable.
With classic projects you can share project configuration between projects. This lets you
ensure consistence across many teams and projects.

As the Jira administrator, you act as the project creator for your Jira community. A user
who has the Administer Jira global permission is the only one able to create classic
projects for all products installed. Members of both the administrators group and the
jira-administrators group have this global permission by default.

To view a classic project and see the issues within it, a user needs both product access
for that product and the Browse projects project permission. We’ll discuss project
permissions in the next module.
If the Jira administrator does not have product access for that product, they will not be
able to see the project’s issues or use project related functionality in the project after
they have created it.

Look at this example. Do you think Dakota can see issues in projects?
She is a member of the jira-administrators group so she has the Administer Jira global
permission. But this doesn't give her the ability to view issues. To do that she also needs
product access. As you can see she doesn't have product access for any of the products
on this site. Without product access, she can configure Jira settings but she can't see
issues in projects.

Here you see some of the project templates for Software and Business project types.
Kanban, Scrum and Bug tracking for the Software project type. Project Management,
Task tracking, and Process control for the Business project type. Each project template
gives you different functionality as a starting point.

When you create a project, choose the project type (and template) that meets your
needs. You also supply the name. Use a descriptive name so the project's easy to find.
The project key will be used as the prefix of this project's issue keys (e.g. ’HR-100'). The key
is automatically generated from the project name (the first letter of each word). You can
change it when you create the project and also later. Choose one that is descriptive and
easy to type.
After you've created a project, you can choose to edit the project details.
For URL, you can use the link to a Confluence space, document repository, etc. for project
documentation.
If you have a large number of projects, you can use project categories to categorize them.
An Avatar (icon) makes the project easier to find. You can use one of the provided avatars
or your own image.
A description makes it clear what the project is for and if you can provide a URL to for e.g.
A Confluence space, more info can be found there.
https://confluence.atlassian.com/display/JIRACORECLOUD/Editing+a+project%27s+details.

When you create a project you can choose to share settings with an existing project.
You'd do this when creating a new project that is similar to another, and you believe the
requirements will stay the same. For example, the Payroll team lead wants a new
project and she wants it set up just like the HR project.
When you create the new project, you choose the project you want to share configuration
with. If a change is made to one of the projects' configurations, that change affects all
the projects that share that configuration. Projects that share configuration share issues
types, workflows, screens, fields, versions, components, permissions, notifications, and
more.

Here's an example of creating a project with shared configuration. We're creating a
project called Android App. We have selected Share settings with an existing project.
We've chosen the iOS App project as the project to share configuration with.

Answers on next slide

Answer: b, you only need Administer Jira global permission to create projects. You would
need product access to view the project you created.

Now we'll introduce project workflow.

Each template for each project type (Software, Service Desk, and Business) has its own
default workflow. In this example you see the default workflow for the Business Project
Management template on the left. It’s a simple workflow with issues typically flowing
from TO DO to IN PROGRESS to DONE. But note the double headed arrows meaning
issues can also flow from DONE back to TO DO or IN PROGRESS, and from IN PROGRESS
back to TO DO. You can also see the transition names for each transition.
On the right is the default workflow for Software projects using the Kanban template.
Issues can move freely on the board between any status. Let's look at this type of
workflow more…

The simplified workflow is a simple, easy to use workflow. It's made up of global
transitions. This means users can transition an issue from any status to any other status
either in the issue itself or by dragging issues freely between columns on the board. The
simplified workflow also means there are no screens displayed on transitions.
Here you see the default workflow for a Scrum software project. It has only three
statuses and issues can freely move between any statuses.
A simplified workflow has no conditions, validators that more complex workflows can
have.
Also in the simplified workflow, the resolution is set and cleared automatically, and that
setting can be made from the board.
The simplified workflow can only be used if a board represents a single project. Also, if
the board was created as a result of creating a project, the board will be using the
Simplified Workflow.

Boards are tied to the underlying workflow. For Software projects, the simplified
workflow is used for the board that’s created when the project is created.
Here’s an example of the workflow for a Software project using the Scrum template. The
top screenshot shows the sprint board in the project. The diagram at the bottom shows
the underlying workflow. Note the connection between columns and workflow statuses.
Each column represents a status in the workflow. In this example the workflow has three
statuses - TO DO, IN PROGRESS, and DONE.
Moving an issue on the board, changes the value of its status and its position in the
workflow.

Board administrators can edit the simplified workflow via board settings, on the
Columns page. Here they can reorder, add and delete columns. Board administrators are
the person who created the board. When the Jira administrator creates the project, the
board is created and they are automatically the board administrator.
They can also add new statuses and add column constraints.

You can edit complex workflows in the workflow editor. Here you can add more
advanced workflow functions such as conditions, validators, post functions, transition
screens, etc. We won't go into editing complex workflows in this course. See the Jira
Cloud Administration Part 2 course.

Now let's look at fields and screens.

Here we see a Create issue screen for creating a bug.
A screen is the user’s view of an issue and is simply a collection of fields. They are the
data entry/view/edit mechanism for issues. The screen is mapped to a specific issue
operation (such as creating an issue, or editing an issue). Jira allows you to display
particular pieces of issue information at particular times, by defining screens. You can
choose which screen to display when an issue is being created, viewed, edited, or
transitioned through a particular step in a workflow.
Information for each issue is held in the fields that are associated with that issue. You
can tailor these fields to suit your organization's needs.

Jira enables you to define field behavior: each field can be required/optional and
hidden/visible. In this example, the Platform field is optional but the Priority field is
required. You can also add a description that will appear when issues are created or
edited. You define this behavior by using a field configuration.
You can configure screens to add and remove fields, reorder fields and break long screens
up into tabs. In this example we remove one field and reorder two others. Removing a
field from a screen will not delete the existing data, nor will it affect search or reporting.
However, if you delete the field itself (not just remove it from a screen), it will destroy the
data in the field.
Don’t create a lot of fields on a screen. Too many fields means users will leave half of
them empty and you can't drive business on bad data.
Note that each user has the ability to configure fields on the Create issue screen, to show
only certain fields. That applies just to what they see.
We'll discuss fields and screens more in the Jira Cloud Administration Part 2 course.


Answer: c, a screen is mapped to a specific issue operation such as creating an issue or
editing an issue.

Now let's introduce you to schemes.

Schemes are probably one of the biggest source of confusion for somebody who is
relatively new to Jira administration, but once you understand the core concept they are
a great way to reduce your administrative overhead while keeping your flexibility up.
A scheme is a container/collection of configuration items. There are many different types
of schemes and each one behaves slightly differently. Schemes allow you to package up
configurations and then re-use them in other projects.
For example, here you see an issue type scheme for Software type projects, Dev Issue
Type Scheme. It contains all the default issue types for that type of project. You can see
the Jira administrator has added the Feature Request issue type. Then the Jira
administrator associated the scheme with all their development projects. If you didn't
use schemes, you'd have to configure each project individually. That could be a lot of
work. And you'd have to repeat it every time you created a new development project.

Here’s another example of a scheme. A workflow scheme allows you to define which
workflows apply to which issue types and projects. Here the DEV: Development
Workflow Scheme is used in the DEV project. There are two workflows in this scheme –
Workflow with review which is applied to Bug and Story issue types and Workflow no
review which is applied to Task and Sub-task issue types.

Only Jira administrators can modify schemes and associate them with projects.
In this example the Jira administrator has updated the Development Permission Scheme
and is associating it with the Legal and Marketing projects.

Best Practices
Don’t add too many fields to a screen. Too many fields means confuse users and they will
often leave half of them empty which creates bad data.
When creating a new project that is similar to another, and you believe the requirements
will stay the same, share its configuration.

Instructor demo

In this module we'll cover how to configure classic project permissions.

This is the third module on project administration in Jira.

Here you'll learn the differences between global permissions and project permissions and
how to edit project permissions in a permission scheme.
The topics covered in this module apply to classic projects, not next-gen projects.

Jira global permissions allow you to control functionality throughout Jira and project
independent. For example, whether users can see the other users in the product. Global
permissions are granted to groups of users and can only be modified by Jira
administrators.
What features users can see and what actions they can take in a classic project are
determined by their product access and project specific permissions. Jira allows you to
control who can access your project, and exactly what they can do in that project, by
using project permissions. These permissions are much more granular than global
permissions. For example, who can see the project's issues, create, edit and assign them.
Project specific permissions let you restrict project related functionality to individual
users, groups or project roles. We'll cover project roles in the next module.

Here are the different types of permissions for classic projects and some examples of
their permissions.
Permissions are divided up into 6 types - project, issue, voters & watchers, comments,
attachments, and time tracking.
Each type has a number of permissions. Here you see a number of the permissions for
each type. For example, whether you can see the project at all is controlled by the project
permission, Browse projects. And whether you can delete issues is an issue permission.
Whether you can manage waters is a voters and watchers permission, and so on.
Not all permissions are listed here.
Note that some permissions are dependent upon others to ensure that users can perform
the actions needed. For example, in order for a user to be able to resolve an issue, that
user must be granted both the Transition Issue permission and the Resolve Issue
permission.
For a list of all the permissions, see
https://confluence.atlassian.com/display/AdminJIRACloud/Managing+project+permissions
You can also control access to individual issues by using security levels and issue
security schemes. These are beyond the scope of this course. See https://confluence.
atlassian.com/display/AdminJiraCloud/Configuring+issue-level+security.

Classic project permissions are defined in permission schemes that are then associated
with projects by the Jira administrator. The project's permission scheme determines who
can do what in a project. Here is an example of a Permission Scheme, the Development
Permission Scheme. As you can see it associates groups (jira-software-users) and project
roles (Administrators and Project Lead) with project permissions.
Permission schemes allow you to create a set of permissions and apply them to any
project. All permissions within a scheme will apply to all projects that are associated
with that scheme. This enables flexible, fine-grained permission control.
In this example, the permission requirements in all development projects are the same.
Members of the Administrators role can administer all DEV projects, only members of the
jira-software-users group can create issues, and only the project lead can resolve issues.
Teams in Space reuses this scheme in all of their dev projects!
Project permissions are able to be granted to individual users, groups, project roles, issue
roles such as 'Reporter', 'Project Lead', and 'Current Assignee’, and 'Public' (e.g. to allow
anonymous access). Typically we wouldn't recommend associating permissions with
individual users.

You can view and edit permissions both from project settings and from Jira
administration. They will both bring you to the Permission schemes page in Jira
administration.
Here you see an example of a permission scheme, HR Permission Scheme, for the Human
Resources project. Project administrators can administer this project and any logged in
user and browse this project. The atlassian-addons-project-access role is created when
you install apps. Jira automatically grants the app the correct permissions for its scope
through this role.

In many organizations, multiple projects have the same needs regarding access. For
example, only the project team can assign and work on issues. Permission schemes
prevent having to set up permissions individually for every project. Once a permission
scheme is set up, it can be applied to all projects having the same requirements. As a Jira
administrator you'll create schemes that match your company-wide processes, or project
types. You'll have a number of projects and each belongs to a certain category of project,
such as a product dev project, or a client project, or an internal project such as finance,
marketing or sales. Each time you set up a new project you can chose the scheme that
reflects the type or project you set up. This is useful to you and your users as:
1. You can manage the number of schemes and keep them to a minimum. Too many
schemes will make your life as a Jira administrator painful.
2. Your users will know how to work within the project as it’s the same as each of the
others, so you don’t need to educate them with each new project that you set up.
In this example, we have an Internal HR Permission Scheme. They have restricted certain
permission like Browse projects and Create issues to just members of the HR group and
Managers. This scheme has been applied to a number of HR projects that have the same
requirements.

What default permission schemes you see, depends on the products you have installed.
You'll always see the Default Permission Scheme. This is used for, and shared by, any
new Business projects which are available with Jira Software, Jira Service Desk and Jira
Core.
If you have Jira Software installed, the Default software scheme will be used for, and
shared by, any new classic Software projects.
Jira Service Desk is different and will create a separate scheme for each Service Desk
project created. We won't cover Jira Service Desk schemes here.

By default the Default software scheme has open permissions with many permissions
given to Any logged in user as you see here on the left. This may be appropriate for most
of your Software projects. However you may have a need in some of your Software
projects to have more restrictive permissions. You can create a more restrictive
permission scheme as you see here on the right and apply that scheme to the Software
projects with more sensitive information. In this example only members of the
Developers group can see and create issues and add comments to issues in the project.

If you edit one of the default schemes it applies to all projects that use it.
To implement different permissions for different projects you can:
1. Make a copy the appropriate default scheme for your projects, depending what type
they are.
2. Edit the copy of the default scheme, updating permissions to meet your needs.
3. Then apply the new scheme to the projects that require the new permissions.

You can assign project permissions to the Public group. This means anyone who has
access to your Jira. Be careful assigning project permissions to Public. Granting the
browse projects permission to Public means issues from projects using that permission
scheme are publicly available on the internet. Granting permission to Public to perform
tasks means people who aren't logged in have permission to perform those tasks on
issues they're permitted to see. For example, edit issues or add comments.
There are situations where you may legitimately want to grant public access to some
projects and issues on your site, like in the case of a public bug tracker.

The Jira Permission Helper can help you diagnose why a user does or doesn't have certain
permissions. You supply the permission to check, the username of the user (leave blank
for anonymous users), and an issue key (for example, an issue that the user can/cannot
see).
In this example we're checking why Max Taylor can't create issues in the Human
Resources project. The permission helper tells us that Max doesn't have the Create Issues
permission.


Answer: A: Default permission scheme
The Default Permission Scheme is used for new Business projects. The Default software
scheme is used for new Software projects.
You could create your own scheme (by copying one of the default schemes). But then
you'd have to apply it to every new Business project you created. Since most of your
Business projects have the same requirements, it's easiest to update and use the Default
Permission Scheme.

Create permission schemes that are shared across similar projects e.g. Development,
that have similar requirements rather than unique schemes for every project. Having a
unique set of schemes for every project will incur too much administrative overhead in a
large installation.
Granting permission to Public to perform tasks means people who aren't logged in have
permission to perform those tasks on issues they're permitted to see. Only do this if you
have that specific requirement.

Instructor demo

In this module we'll cover how to configure classic project roles.

This is the last module on classic project administration.

Here you'll learn the advantages of using project roles.
You'll also learn how to assign the project administrator role to delegate some
administration responsibilities for a project.
And how to assign the project lead and default assignee roles for a project.
You'll learn how to create a project role and add members and how to edit a new
permission scheme using roles to control what users can do in a project.

First let's look at what project roles are.

Project roles are a flexible way to associate users and/or groups with particular projects.
The members of project roles are users or groups of users who fulfill particular functions
for a project.
Jira administrators can define project roles then all projects have those project roles
available to them.
Project administrators assign members to project roles specifically for their project(s).
In this screenshot you see the People page for a project. The Administrators project role
has been assigned to Sophie Nguyen. And the Members role has been assigned to the
Development group. Another project could have a different user assigned to the
Administrators role and a different group, or users, assigned to the Members role.

Project roles are similar to groups, the main difference being that group membership is
global whereas project role membership is project-specific.
Project roles are defined in Jira administration so the role is global but the members are
defined for each project and are typically different for each project. Only site or Jira
administrators can create project roles. Only site administrators can create groups.
Additionally, group membership can only be altered by site administrators, whereas
project role membership can be altered by project administrators (or site or Jira
administrators).
For more information on project roles, see http://go.atlassian.com/cloudprojectroles.

Different people may have different responsibilities in different projects — the same
person may be a leader of one project but an observer of another. Jira enables you to
assign particular people to specific responsibilities in your project. Project Lead, Default
Assignee and Project Administrator are automatically created for all projects. These
could be different people or the same person as shown in the slide.
• The Project Lead is the person who manages the project, for example, the Project
Manager or the Lead Developer. This role can be used in schemes and can be used as
the 'Default Assignee.
• When a new issue is created, if an assignee isn't specified, the project's Default
Assignee is used. This can be either the Project or Component Lead, or Unassigned (the
default). In Jira's general configuration, the setting ‘Allow unassigned issues’ is set to
ON by default. Turn this off if you don’t wish to allow unassigned issues.
• The Project Administrator can edit the project details as well as the project lead. They
can also change the project type, define project components and versions. They can
also view, but not select nor edit the project's schemes. But probably their most
important responsibility is to edit project role membership. Jira administrators always
have Administrators role in a project. The default schemes are configured to use this
role.

Project roles allow Jira administrators to delegate power to project administrators and
take some work off their hands.
After the Jira administrator has created a project, they assign the Administrators role to
the person who will administer the project. Once that person becomes a project
administrator they then have the power to assign another person to the Administrators
role in the project.
The Administrators role can be assigned to an individual or a group. In this example,
Sophie Nguyen, has been assigned the Administrators role in the Android App project so
she is the project administrator.
In the default permission schemes, the Administer Project permission is granted to the
Administrators project role by default.

In addition to the automatic roles created for every project, Jira administrators can
create their own custom roles that apply across projects. You can use these roles in
schemes that can be shared across projects. And then each project can have unique
members for the role.
To create and assign members to custom roles:
1. The Jira administrator creates custom project roles in Jira administration so all
projects have the same project roles available to them.
2. The Jira administrator adds project roles to schemes. The core usage for project 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.
3. The Jira administrator then associates the scheme with a project.
4. Then Project administrators assign members to project roles specifically for their
project(s). Of course the Jira administrator can also assign project members to project
roles but ideally they'd delegate this work to the project administrator.

Now let's walk through a project roles and schemes scenario.

In this scenario, the project administrator for the Human Resources project wants two
consultants on her project to be able to create issues in her project temporarily. This
would mean they would need the Create Issues permission. Other projects also use
consultants.
What are the options? See next slide.

Option 1 – use a group to update a shared scheme:
1. The Site administrator creates the Consultants group and adds all consultants for all
projects to this group.
2. The Jira administrator updates the shared Business Permission Scheme and adds the
Consultants group to the Create Issues permission.
This would be an easy change for the Site administrator and the Jira administrator but is
this a good option?
In this scenario three Business projects are sharing the Business Permission Scheme -
Human Resources, Marketing and Sales.
The problem with using a group to update the shared scheme is that all members of the
consultants group can create issues in all the Business projects that use this scheme.
Each project only uses a couple of consultants and they're different for each project.
This is too much access for the members of the Consultants group. So this is not a
desirable option. Also it involves three different people (assuming the Site administrator,
Jira administrator, and Project administrator roles are done by separate people) to make
the change.

Option 2 – use groups to update new schemes:
1. The Site administrator creates the HR Consultants group and adds each consultant.
2. The Jira administrator:
1. Copies the Default Permission Scheme to create a new HR Permission Scheme.
2. Updates the HR Permission Scheme and adds the HR Consultants group to the
Create Issues permission.
3. Associates the HR Permission Scheme with the Human Resources project.
Then the Jira administrator goes through the same process for the Marketing project,
creating the Marketing Consultants group and a Marketing Permission Scheme.
This solves the problem of one Consultants group having permissions in many projects.
Is this a good option?
Since requirements are often very specific (different teams, stakeholders, etc.), this sort of
situation could come up for many different projects. So the Jira administrator would have
to create many schemes and be involved in every requested change. Each project’s
scheme would need to be changed every time there’s a change in the requirement.
This incurs a lot of administrative overhead, is time consuming and does not offer much
flexibility. Also, having many, many schemes can possibly incur a performance hit.
Also it involves three different people to make the change (assuming the Site, Jira, and
Project administrator roles are done by separate people).Maybe there’s a better way …

The solution is to use project roles. In this scenario the Jira administrator:
1. Creates the Consultants project role
2. Copies the Default Permission Scheme to create the Business Permission Scheme.
3. Adds the Consultants project role to the Create Issues permission in the scheme.
4. Associates the Business Permission Scheme with all projects that use consultants.
Finally the project administrators in each project add their consultants to the
Consultants project role.
Initially there’s a bit of work for the Jira administrator to do. But it’s a lot easier each time
a request comes up. The Jira administrator just needs to associate this permission
scheme with the new project and let the project administrator define their own
members. Also only the Project administrator and Jira administrator are involved.
Here we see the power of roles and schemes. You use roles in schemes. Then you share
the schemes among projects. By assigning the Create Issues permission to a project role
whoever has that role in a particular project, will get that permission. So in this example,
consultants Ravi and Sue can create issues in the Human Resources project, Sam, Ava,
and Nalini can create issues in the Marketing project, and the Sales Consultants group
can create issues in the Sales project. By using project roles you can use fewer
permission schemes. Fewer schemes can mean better performance. It also means you
can share schemes and save a lot of administration work. That means you can focus on
the tasks that can’t be delegated to project administrators.

Here's another example of custom roles. If your organization requires all software
development issues to be tested and then closed by a Quality Assurance (QA) person, you
could do the following:
1. Create a project role called QA.
2. Create a permission scheme called Dev Permission scheme, in which you assign
the ’Resolve Issues' permission only to the QA project role.
3. Associate the Dev permission scheme with all software development projects.
4. For each software development project, add the appropriate QA people to the QA
project role. For example in the Astronaut App, Dave and Mary have been assigned
this role. Whereas in the Rocket App project Amit, Sara, and Joe have been
assigned to the QA role. And in the Music App project the Musical QA group has
been assigned to the QA role.


Answer: a, b, and d
Using roles in permission schemes means you can create fewer schemes, you reduce your
administrative overhead and also avoid the use of users and groups in schemes.

As a best practice we advise the use of project roles within Jira wherever possible to
allow the use of fewer permission schemes. Avoid using individual users in permission
schemes and use groups only sparingly.
Create schemes that are shared across similar projects e.g. Development, that have
similar requirements rather than unique schemes for every project. Having a unique set of
schemes for every project will incur too much administrative overhead in a large
installation.

In this module we'll cover how to create and configure next-gen projects.

This is the final module on project administration and in the course.

Here you'll learn how to create next-gen projects, control access to your projects, add
issue types, and add fields for issue types in your projects.
You'll also learn how to configure a project board and customize the features of your
project.

Next-gen projects are fast to set up, easy to configure, and user-friendly.
Users can by default create and manage their own next-gen projects.
And all changes that are made to a next-gen project apply only to that project and don't
affect other projects.
For more information, see http://go.atlassian.com/cloudmangenextgen.

By default, any logged in user can create next-gen projects. Out of the box, Jira gives
users the Create next-gen projects global permission. Jira administrators can prevent
users from creating next-gen projects by managing which groups are granted this
permission.

Here you see project templates for next-gen projects. Currently there are two for
Software projects - Kanban and Scrum.
And you also see three of the Service Desk templates - IT service desk, General service
desk, and External service desk. There are more.
More templates are being added all the time.

When you create a next-gen project you supply the name. Use a descriptive name for the
project so it’s easy to find.
The project key will be used as the prefix of this project's issue keys (e.g. ’GA-10'). The key
is automatically generated from the project name (the first letter of each word). You can
change it when you create the project and also later. Choose one that is descriptive and
easy to type.
You also choose the appropriate access level. We'll discuss these on the next slide.
A project icon makes the project easier to find. Use a meaningful icon to make the project
easier to find. You can use one of the provided avatars or your own image.
https://confluence.atlassian.com/display/JIRACORECLOUD/Editing+a+project%27s+details.

When you create a next-gen project you can choose from three levels of access:
• Open allows anyone with access to your site to create and edit issues in the project.
This means that project team members don't have to be separately added to the
project, because they can already do their work there.
• Limited means that anyone with access to your site can view and comment on issues,
but they cannot create and edit issues. Team members that need to create and edit
issues must be added to the project.
• Private means that only people who have been added to the project can see the
project. This is a way to prevent the project's issues from being widely visible in the
organization. Other people on your site will never know the project exists. Jira
administrators can see private projects in the project directory, but they don't have
access to view or interact with a private project's issues (unless they have been added
to the project).
You can change the access level for a project at any time.

Next-gen software projects come with the following project roles:
Project administrators can do most things, like update settings and add other
administrators to the project. They can manage features, customize issue types, and add
rules on the board.
Members are a part of the team. They can create issues, edit them, comment on them,
move them into different statuses, and generally collaborate on your project's work.
Viewers can search through and view issues in your project.
Project administrators can add people to their projects and set their roles. The person
who creates the project is automatically given the Administrator role.
If a user is assigned multiple roles in a project, the most permissive role wins.
There are also other roles for Jira Service Desk next-gen projects which aren't covered
here.
For details on what users can do in each role, see
http://go.atlassian.com/cloudnextgenperms.

The project administrator can edit the default issue types and add new issue types in a
next-gen project. For example, next-gen Software Scrum projects come with the Epic,
Bug, Story, Tasks, and Sub-task issue types by default. Next-gen Kanban projects come
with Task and Sub-task issue types by default.
You can customize your issue types to match any method of project management you
want. You can delete any of the default issue types in the project, you can rename the
issue type or update the description, etc.
You can also create new custom issue types. For example, in a Software Kanban project,
you may want to add a Document issue type for any updates needed to the
documentation.

Fields on an issue are divided up into different sections:
1. Description fields - appear in the main content area of your issues.
2. Context fields - appear on the right side of your issues.
3. Hide fields below dotted line - appear on your issues when someone completes the
field. If the field is empty, it's hidden. Users select Show more when viewing the issue
to see and interact with the hidden fields.
This becomes important when you add fields. Let's look at that ...

The foundation of every Jira issue is its key, summary, and a status. But some tasks
require more information to help along the team taking on that work. Project
administrators can customize each issue type to show different fields. You can add,
reorder or remove fields and also create custom fields.
By default, Jira adds a few fields to your issue types that we think help provide context to
your project's work. They are Summary, Description, Status, Assignee, Reporter, and
Labels. Jira also comes with a few commonly-used fields you might consider adding, for
example, Priority and Due Date.
When you add a field you select what part of the issue you want it to appear in:
Description, Context or Hidden (see previous slide).
Don’t add too many fields as this can confuse users and they will often leave half of them
empty which creates bad data.
For more information, see http://go.atlassian.com/cloudnextgenfields.

Customizing your next-gen project workflow is simply done by editing the board. Drag
columns to be in any order you want. Click + to create new columns. And you can set
column limits. The column with highlight if the limit is exceeded.
An example of editing your workflow is if you added a Review step to your work process.
You could add a Review column and move it to be between In Progress and Done.
Don’t add too many columns as the board will become difficult to use.

Next-gen projects are very flexible. You can start with the features of a kanban project
and as your needs change you can add features to make it a scrum project i.e. by turning
on Sprints and Estimation. You can change these features at any time. So it doesn't
matter what template you initially choose when creating a next-gen project, you can
always change it.

Next-gen projects don't have schemes so any changes made in a next-gen project apply
only to that project. If you edit the workflow or the issue types, create any new issue
types, add fields to screens, etc. no other projects are affected. And if, for example, you
add a new issue type to a project. When you go to the Issue Types Jira administration
page you won't see the issue type there. That page only shows classic project issue
types.
Note that in the future, next-gen projects may be able to share project configurations.

Atlassian Marketplace apps add new functionality to your next-gen projects. Use them to
integrate third-party tools and add-ons into your project. When your Jira administrator
integrates third-party apps to your Jira site, project administrators might have the option
to display or hide the app's functionality in their next-gen projects and adjust their
settings.
Go to project settings > Apps. Most apps have a toggle that changes their display setting.
You can easily display or hide the app from your project by flipping on or off this toggle.
In this example, we see the Slack integration apps page. You can display or hide the
Slack panel on issues in the project. You can also add channels to receive notifications.
You may not see a settings page for every app installed on your Jira site. Each app’s
settings options are provided by the developers who built them.
If you want more information about an app or how to set it up for your project, check the
developer’s website or Atlassian Marketplace listing.

New features are being added to next-gen projects all the time. Check out upcoming
features in the Atlassian roadmap at atlassian.com/software/jira/whats-new/next-gen.


Answer: c If a user is assigned multiple roles in a project, the most permissive role
(Members) wins. Members can add and edit issues.
Users can be assigned multiple roles in a project.
And access for a project can be changed at any time.

Don't create too many fields for an issue type as this will just confuse users and they may
leave many of them blank which results in bad data.
Don't create too many columns on the board as it becomes difficult to use.
You can enable or disable project features such as Backlog, Sprints, etc. at any time to
create your own flavor of agile.

Atlassian skills are in high demand in the job marketplace. The path to Atlassian
certification is designed to help you deepen and expand your Atlassian skills, and
prepare you to take on your next challenge.
Follow the path to Certification – you’ll propel your career, boost your skills and learn
new ways to help your teams do their best work.
To find out more, visit atlassian.com/certification.

Training for Jira is a new Marketplace app containing a growing collection of short,
interactive tutorials, designed to get teams over the hump and using Jira quickly.
Why Training for Jira?
• Help teams help themselves to training and reduce the number of Jira questions.
• Training for Jira scales – it’s built right into Jira and is available to everyone.
• The tutorials are short and topic-focused; users can choose what to learn and when.
• The app also keeps track of users’ progress so they can see where they left off, and so
managers can track the progress of their teams.
The Tutorials…
• Cover popular topics and tasks
• Introduce essential concepts
• Showcase in-product demos
• Include non-graded quizzes so you can see if you’re getting it
• Have optional voice-over narration and closed captions
Available for Cloud, Server, and Data Center
Learn more
• Search for “Training for Jira” from marketplace.atlassian.com to download a free trial.
• Requires internet connectivity to access content
• Note: If you're using a firewall or have network restrictions where Jira is installed, you
may need to whitelist IP addresses to access this app.

Training credits give you a prepaid account for Atlassian product training.
Simplified Approvals
Training credits allow your procurement team to establish a 12-month burn-down
balance for Atlassian training. With this simple arrangement, you'll no longer need to
process repeated purchase approvals for small transactions.
Volume Discounts
By pre-paying for training as an annual credits program, you can take advantage of
volume training discounts to get a more effective return on your training budget.
Fast Access
With training credits, you reduce the purchasing delays for your business users and make
it faster to access the training they need.

Here are a list of resources to explore if you want to learn more.

We encourage you to join your local Atlassian Community Events group.
You'll meet a diverse group of Atlassian users who come together to share best practices
and socialize.
To join a group near you, go to aug.atlassian.com.
And if there's no ACE nearby start one. Go to aug.atlassian.com/leaders to sign up.
And don't forget that you can always connect with fellow users on
community.atlassian.com.

Now that you've completed the course, please take the survey and give us your feedback.

Congratulations on completing the course!

Язык

Добро пожаловать в Scribd!

Jira-Admin-Pt1-Cloud-SG-APR272020.pdf

Загружено:

Сведения о документе

Дата загрузки

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Доступные форматы

Jira-Admin-Pt1-Cloud-SG-APR272020.pdf

Загружено:

Описание:

Авторское право:

Доступные форматы

Похожие издания

1 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

2 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

3 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

4 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

5 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

6 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

7 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

8 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

9 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

10 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

11 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

12 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

13 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

14 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

15 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

16 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

17 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

18 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

19 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

20 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

21 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

22 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

23 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

24 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

25 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

26 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

27 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

28 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

29 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

30 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

31 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

32 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

33 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

34 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

35 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

36 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

37 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

38 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

39 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

40 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

41 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

42 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

44 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

45 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

46 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

47 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

48 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

49 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

50 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

51 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

52 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

53 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

54 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

55 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

56 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

57 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

58 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian

59 Jira Administration Part 1 - Cloud Copyright © 2020 Atlassian