VIDEO 17

Epics

Reproducir video
reproducir
Volumen
0:00/7:26
Ajustes
Pantalla completa
Notas

Todas las notas

Haz clic en el botón Guardar nota cuando desees capturar una pantalla. También puedes
resaltar y guardar líneas de la siguiente transcripción. Añade tus propias notas a lo que hayas
capturado.

Guardar nota
Discutir
Descargar

Ayúdanos a traducir

Transcripción interactiva: para habilitar el modo de transcripción básico, presiona la tecla de escape
Puedes navegar a través de la transcripción usando la pestaña. Para guardar una nota para
una sección de texto, presiona CTRL + S. Para expandir tu selección, puedes usar CTRL + la
tecla de flecha. Puedes contratar tu selección usando Shift + CTRL + tecla de flecha. Para los
lectores de pantalla que no son compatibles con el uso de teclas de flecha para accesos
directos, puedes reemplazarlos con las teclas H J K L. Algunos lectores de pantalla pueden
requerir el uso de CTRL junto con la tecla alt.
Play video starting at 2 seconds and follow transcript0:02
In this video we will discuss Epics.

Play video starting at 6 seconds and follow transcript0:06

We will start with an overview of Epics.

Play video starting at 10 seconds and follow transcript0:10

We have discussed stories, tasks, bugs and subtasks. 
An Epic is an issue type that has a bigger scope than all of these. 
How they are actually used is up to the team. 
This video will contain some ideas on how to use them. 
An Epic is a large issue.

Play video starting at 30 seconds and follow transcript0:30

An Epic can span multiple iterations, projects, teams, and boards.

Play video starting at 36 seconds and follow transcript0:36

It can serve as a placeholder for many stories. 
For example, an epic might be to create an iPhone version of an app. 
You would then break this into stories when the team is available to 
actually work on it. 
An epic can contain issues. 
They can contain stories, tasks, bugs, custom issue types, and 
can even contain subtasks.

Play video starting at 1 minute 0 seconds and follow transcript1:00

Epics are useful because they provide an organization of the team's work, 
rather than having unrelated issues. 
They are useful if the work spans multiple iterations. 
Also having one placeholder story to represent a lot of work can simplify 
the backlog. 
You don't want to create detailed plans too early. 
Next we will discuss working with epics.

Play video starting at 1 minute 25 seconds and follow transcript1:25

You can create an Epic by selecting the Epic Issue Type when creating an issue.

Play video starting at 1 minute 31 seconds and follow transcript1:31

Here we have created an Epic named, 
Big Feature A If you want to add an issue to an Epic 
when you are creating an issue you select the epic from the epic length drown. 
All issues with this epic length value belong to the epic.

Play video starting at 1 minute 47 seconds and follow transcript1:47

You also can add an existing issue to an epic 
at a time using the epic link drop down.
Play video starting at 1 minute 55 seconds and follow transcript1:55
To view the issues of an epic, you can open the epic issue.

Play video starting at 2 minutes 0 seconds and follow transcript2:00

Issues that belong to this epic are shown.

Play video starting at 2 minutes 4 seconds and follow transcript2:04

The kanban board can show the epic issue itself, and 
any issues that belong to it are labeled.

Play video starting at 2 minutes 10 seconds and follow transcript2:10

Here you can see the epic issue, and the story that belongs to the epic.

Play video starting at 2 minutes 16 seconds and follow transcript2:16

If you view an issue belonging to an epic, 
you will see the epic in the Epic link field. 
You can click on the link to view the epic.

Play video starting at 2 minutes 24 seconds and follow transcript2:24

At some point you might realize that an existing story is bigger than you thought 
and want to convert it to an epic. 
You can do this by changing the Issue Type to Epic.

Play video starting at 2 minutes 35 seconds and follow transcript2:35

When your project has Epics, you can configure Swimlanes by Epic. 
Navigate to the Swimlanes tab of the board's settings and 
select Epics from the base Swimlanes on drop down. 
Each Epic will automatically have its own Swimlane. 
We're showing swimlanes for a kanban board here, but 
swimlanes can also be configured with scrum and agility boards.

Play video starting at 2 minutes 58 seconds and follow transcript2:58

Here we see our epic swimlane. 
The issues of the epic are separated from the rest of the issues on the board.

Play video starting at 3 minutes 7 seconds and follow transcript3:07

An epic is an issue type in Jira, and like all issue types, has an issue key.
Play video starting at 3 minutes 13 seconds and follow transcript3:13
If an issue is part of an epic, its epic link field contains the issue 
key of the epic issue which can be thought of as its parent. 
Here we are searching for all issues that are part of this epic. 
We can use Jira's autocomplete to help create this query.

Play video starting at 3 minutes 31 seconds and follow transcript3:31

Next, we will discuss epics and kanban backlogs.

Play video starting at 3 minutes 37 seconds and follow transcript3:37

If you enable a kanban backlog on a kanban board, 
you have the option of enabling the Epics panel. 
This will display an epic in the panel in the backlog instead of 
as a card on the board.

Play video starting at 3 minutes 50 seconds and follow transcript3:50

Once you have enabled the Epics panel in the kanban backlog, the Epic issue will 
no longer appear on the board independent of the status of the Epic issue. 
Here, we are viewing only issues of our epic that have a status of backlog. 
You can see that there is currently one issues for 
our epic that is in the backlog. 
You only want to enable the epics panel if your epic issue has child issues. 
If the epic is currently an issue with no child issues, 
you do not want to use the epics panel, 
because the epic will not appear as an issue on your board, or in your backlog. 
Notice that there is a Create epic link in the epics panel. 
This is an alternative to creating an epic by creating 
an issue with an issue type of epic.

Play video starting at 4 minutes 36 seconds and follow transcript4:36

You can mark an epic as done by selecting the drop down next to the epic name and 
selecting mark as done. 
If you try to mark an Epic with incomplete issues as done, 
Jira will warn you and ask you to confirm. 
When you confirm, the Epic status field will be set to done.
Play video starting at 4 minutes 58 seconds and follow transcript4:58
Next we will discuss Epics and scrum.

Play video starting at 5 minutes 3 seconds and follow transcript5:03

In a scrum project, 
you can click Create epic under the epics tab of the product backlog. 
This is similar to creating an epic from the kanban backlog. 
The Create epic dialog will open. 
You can see that this is like creating an issue and 
selecting epic as the issue type.

Play video starting at 5 minutes 23 seconds and follow transcript5:23

You can use the Epics panel in the backlog to monitor the current status of the epic.

Play video starting at 5 minutes 30 seconds and follow transcript5:30

Notice the Create issue in epic link. 
You can start the process of creating an issue in the epic here.

Play video starting at 5 minutes 39 seconds and follow transcript5:39

You can mark an epic as done in the background in the same way that it is done 
for kanban projects. 
Click Mark as done from the drop down next to the epic name.

Play video starting at 5 minutes 51 seconds and follow transcript5:51

When you mark an epic as done it no longer shows up in the epic's panel of 
the backlog. 
The epic status field for the epic issue is set to a value of done.

Play video starting at 6 minutes 2 seconds and follow transcript6:02

If you want to undo an epic marked as done, you can search for 
issues with an epic status field set to done.

Play video starting at 6 minutes 9 seconds and follow transcript6:09

This shows the epic that we just marked as done. 
From the more menu in the upper right, you can select the Bulk change option.

Play video starting at 6 minutes 19 seconds and follow transcript6:19

Select Edit issues to edit the epic.
Play video starting at 6 minutes 24 seconds and follow transcript6:24
Click the Change Epic Status box and change the Epic Status to In Progress.

Play video starting at 6 minutes 32 seconds and follow transcript6:32

After making the change to the Epic Status, 
you will see your Epic back in the Backlog.

Play video starting at 6 minutes 39 seconds and follow transcript6:39

Under the Reports tab you can view the Epic Report. 
This shows the current status of the Epic as well as the list of its issues.

Play video starting at 6 minutes 49 seconds and follow transcript6:49

You can view the epic burndown chart to see your progress on the epic as you 
complete sprints.

Play video starting at 6 minutes 56 seconds and follow transcript6:56

Here is a review of what we discussed in this video.

Play video starting at 7 minutes 0 seconds and follow transcript7:00

An epic is a large issue of issue type epic that may contain other issues.

Play video starting at 7 minutes 7 seconds and follow transcript7:07

The epic link field is used to associate issues with an epic.

Play video starting at 7 minutes 13 seconds and follow transcript7:13

Epics can be shown on boards or in backlogs.

Play video starting at 7 minutes 17 seconds and follow transcript7:17

Now it's time for 
you to work on some of the things that we discussed in this video. 
Separate hands-on instructions are provided for you.

VIDEO 18

Versions

Reproducir video
reproducir
Volumen
0:00/14:45
Ajustes
Pantalla completa
Notas

Todas las notas

Haz clic en el botón Guardar nota cuando desees capturar una pantalla. También puedes
resaltar y guardar líneas de la siguiente transcripción. Añade tus propias notas a lo que hayas
capturado.

Guardar nota
Discutir
Descargar

Ayúdanos a traducir

Transcripción interactiva: para habilitar el modo de transcripción básico, presiona la tecla de escape
Puedes navegar a través de la transcripción usando la pestaña. Para guardar una nota para
una sección de texto, presiona CTRL + S. Para expandir tu selección, puedes usar CTRL + la
tecla de flecha. Puedes contratar tu selección usando Shift + CTRL + tecla de flecha. Para los
lectores de pantalla que no son compatibles con el uso de teclas de flecha para accesos
directos, puedes reemplazarlos con las teclas H J K L. Algunos lectores de pantalla pueden
requerir el uso de CTRL junto con la tecla alt.
Play video starting at 0 seconds and follow transcript0:00
In this video, we will discuss versions. 
We will start with the versions overview. 
A version is a set of issues for a project that are 
usually considered to be a single product update. 
The word usually is used here because it is up 
to the team to decide the purpose of the version. 
A version is also called a release. 
Here's a version in project A that we named 0.1. 
This version contains four issues. 
Versions in Jira serve a number of purposes. 
It's up to every team to decide how they want to use them. 
The sets of issues and versions are a way to organize issues. 
You can easily find the issues related to any version. 
If your project has a number of fixed release points, 
versions in Jira help schedule them. 
Identifying issues for release and specifying 
unexpected release date sets a goal for the team. 
Versions can be used in queries and reports. 
For example, you could view all of the stories that were completed in 
a specific version or view 
a report on the progress of the version that you are working on. 
Versions can also be used to remove done issues from kanban boards. 
Kanban boards have a continuous flow of issues, 
and versions are a way to prevent the done column from continuously growing in size. 
Scrum does not have this problem because sprint boards have 
a relatively fixed number of issues and have shorter lives. 
The primary field related to versions is the fixVersion field. 
If the fixVersion field of an issue has a value, 
the issue belongs to a version. 
Here we are editing an issue. 
You can see that there's a fixVersion field with a value of none. 
This issue does not belong to any versions. 
It is not editable here because no versions have been defined for this project. 
FixVersion is a bit of a historic name. 
Jira primarily started out as a bug tracker for software projects. 
FixVersion originally represented the version of the software where the bug was fixed. 
There's also an affectsVersion field which 
typically represented which version the bug was founded. 
In none bugs situations, 
you can think of the fixVersion field as 
the primary version field because it applies generally to all types of Agile issues. 
Each version has a version status. 
An unreleased version is a set of issues in preparation for a release. 
For example, a team could create an unreleased version 
and assign five issues from the backlog to be part of that version. 
The released version usually represents 
a set of issues that have been delivered to the customer. 
An archived version is an historic set of delivered issues. 
Jira hides this version from the user interface and release reports. 
An archived version is a relatively subtle concept in Jira. 
Issues in all versions are still query-able. 
As long as you have permission to see the issues, you can search for them. 
They still belong to a project. 
There are two general stages of working with a version. 
The first is to create the version. 
When you do this, you assign it a name and 
other optional metadata such as its release date. 
The version has an unreleased version status. 
The team can then add issues to the version in preparation for release. 
When the issues of the version are done, 
the version can be released. 
The version status is changed to released or archived. 
We will first discuss working with versions independently from a board. 
We'll then see that from a kanban board. 
You can combine these stages, 
creating and releasing the version in one step. 
Next, we will discuss two-stage releases. 
To begin creating a version, 
you can click on the Releases tab in the project sidebar. 
This method of creating a version is independent of 
boards and can be used for issues in any type of project, 
including kanban and Scrum projects. 
When you click on the Release button, 
you are prompted to enter the version metadata. 
You must specify a version name. 
It can be a number such as 0.1 or any other name such as a code name for the release. 
Optionally, you can enter a start date, 
release date, and description. 
When you specify the release date that is in the future, it is a goal, 
and Jira will inform you by displaying 
the version named in red if your release is overdue. 
Another way to create a version for Scrum projects is from 
the Versions tab of the Product Backlog using the create version link. 
For kanban projects, if you have the kanban backlog enabled for your board, 
you can create a version from the backlog. 
Just like with Scrum projects, 
there's a Versions tab containing a create version link. 
Here's the Releases tab after we create aversion. 
Notice that when you create a version, 
it has an unreleased status. 
Also notice that it contains no issues. 
The version is ready to have issues added to it. 
To add an issue to a version, 
open the issue and click on its fixVersions field. 
You can then select the version or versions that you want to add the issue to. 
You usually makes sense to add it to a single unreleased version, 
but you could also add it to a released version. 
You can use the Releases tab in 
the project sidebar to view details of the release at anytime. 
Here's our unreleased version containing one done issue. 
If you create a version and have a number of 
existing issues that you would like to add to it at once, 
you can both change the issues. 
Here we have performed a basic search, 
where we search for issues from our project that are either in the selected for 
development or in-progress statuses and do not have the fixVersion field set. 
Assuming that these are the issues that we would like to add to the release, 
we can click on the More menu in the upper right and select Bulk change alt issues. 
After selecting the issues that you want to add to a version, 
you can select Edit issues to begin 
the process of adding a fixVersion value to the issues. 
You then check the change fixVersions box 
and can add the unreleased version as a value for the field. 
For Scrum projects, you can add completed issues from a sprint to a version. 
Here we have done a basic search for issues 
from a completed sprint with a status of done. 
We can then bulk add these issues to our version. 
We can view our version under the Releases tab in 
the project sidebar and see that the issues have been added to the version in bulk. 
We can see the current progress of the version, 
including workflow status of each of the issues. 
You can click on the View in Issue Navigator link 
to view the list of issues as a query result. 
Here's a list of issues from the version in the issue Navigator. 
You can see the query that is used to show these issues. 
The query is scoped to a project because projects may use the same version naming scheme. 
The fixVersion field is used to find issues from version 0.1. 
If you view the details of an issue in a version, 
you will see that the version name is assigned to the fixVersion field. 
You can click on the version name to switch to the issue navigator, 
showing the issues of version. 
As you are working on a version, 
you can view version related reports, 
such as the version report shown here. 
This applies mainly to Scrum projects. 
This shows you your story point progress to see 
if you are on track to release the version on time. 
To release a version, 
you click the release button. 
If you click the Release button when some of the issues are not done, 
Jira will warn you and ask you if you really want to do this. 
You can release a version in this state but usually you 
want all of the issues to be done before releasing them. 
When the issues of the release are done, 
you can click the release button, 
specify the release date, 
and click the release button to change the version status to released.

Play video starting at 8 minutes 44 seconds and follow transcript8:44

On the releases page, 
there's also a more icon to the right of 
each release containing actions related to the releases. 
Unreleased will change the release status to unreleased. 
In our case, the issues will appear again in the done column of 
the Kanban board but the issues we'll still have a fixVersion of 0.1. 
Archive will change the version status to archived. 
The version will appear in less of the release 
related user interface elements and reports. 
Edit allows you to change the metadata related to the version. 
Delete removes the version. 
You must choose what happens to the issues of the version. 
You can either move the issues to a different version 
or simply clear the fixVersion value for the issues. 
This does not delete any issues. 
If you have multiple versions, 
you also have the merge option for releases. 
You select the merge option for the release that you want to merge into another version. 
Here we will select Merge 0.1 version. 
You then select which version to merge into. 
All of the fixVersion values will be changed to 
this version and version 0.1 will no longer be available.

Play video starting at 9 minutes 59 seconds and follow transcript9:59

Next, we will discuss kanban board releases. 
Another fundamental way to create a release is from a kanban board. 
A kanban board contains a continuous flow of issues. 
There are always issues moving to the Done status. 
Anytime that there are issues in the Done column, 
the "release" dropdown in the upper right is enabled. 
If you are ready to release you can create a version that contains 
the Done issues by selecting the new version option from the "release" dropdown. 
This allows you to create the version and release it at the same time. 
In this example, if we create the release 
now it will contain these four issues from the Done column. 
When creating the release, 
you specify the version metadata like you did previously. 
The release date will automatically be filled out for you 
because you are creating and releasing the version in one step. 
For this same reason, 
there is no start date on this form. 
Clicking release will create the release with 
the released status and containing the 4 issues. 
Notice that after their release, 
the Done column has been cleared and the "release" dropdown is not 
enabled because there are no issues in the Done column to release. 
Next we will look at what happened to the issues that were in the Done column. 
We have seen that boards have filters which define the issues that appear on the board. 
If you scroll to the bottom of the General tab for 
the board settings you will see that there is also a sub filter, 
this is an additional filter that limits the issues displayed on the board. 
The sub filter is what makes the issues and 
the Done column disappear from the board when you release a version. 
The sub filter is allowing any issue with an empty fixed version field to remain 
on the board as well as any issues that belong to a version that has not been released. 
The query is using the unreleased versions JQL function to determine the version status. 
Any issues with the fixed version value of aversion that has 
a version status of released or archived will not appear on the bullet. 
If you also wanted to view all done issues on 
the board you could create another board and remove this subfilter.

Play video starting at 12 minutes 19 seconds and follow transcript12:19

Here are the version related JQL functions. 
You can find these in the advanced searching functions reference. 
There are two functions related to unreleased versions. 
The first is the unreleasedVersions function, 
the project argument is optional. 
If you don't pass a project name, 
the function applies to issues of all projects of the Jira column. 
As an example, this query searches for all issues in 
the project A project that are in any unreleasedVersions. 
We just saw that this function is used in a some filter for the project board 
so that issues that are part of an unreleasedVersion still appear on the board. 
The earliest unreleasedVersion function searches 
for issues in the oldest unreleasedVersion. 
This is probably the next version to be released. 
The two functions related to the ReleasedVersions are 
basically the opposite of the unreleased functions. 
The ReleasedVersions function helps search for all issues that have been released, 
the latestReleasedVersion function searches 
for issues that were in the most recent release. 
You can use the releases tab in 
the project sidebar to view the version that you just released. 
Makes sure that the version status filter is set to all statuses and 
your release will appear containing 
the metadata that you specified when creating the version. 
Notice that the status is released. 
Here's a review of what we've discussed in this video. 
A version is a set of issues from a project that are 
usually considered to be a single product update. 
If the fixVersion field of an issue has a value, 
the issue belongs to a version. 
Versions have a version status unreleased, released or archived. 
Add multiple issues to a version by bulk changing the fixVersion field. 
The "release" dropdown on a kanban board allows you to create 
and release a version that includes all done issues on the board. 
The default kanban board subfilter 
removes done issues if they are part of a released version.

Play video starting at 14 minutes 35 seconds and follow transcript14:35

Now it's time for you to work on some of the things discussed in this video, 
separate hands-on instructions are provided for you.

VIDEO 19

Users and Groups

Reproducir video
reproducir
Volumen
0:00/8:47
Ajustes
Pantalla completa
Notas

Todas las notas

Haz clic en el botón Guardar nota cuando desees capturar una pantalla. También puedes
resaltar y guardar líneas de la siguiente transcripción. Añade tus propias notas a lo que hayas
capturado.

Guardar nota
Discutir
Descargar

Ayúdanos a traducir

Transcripción interactiva: para habilitar el modo de transcripción básico, presiona la tecla de escape
Puedes navegar a través de la transcripción usando la pestaña. Para guardar una nota para
una sección de texto, presiona CTRL + S. Para expandir tu selección, puedes usar CTRL + la
tecla de flecha. Puedes contratar tu selección usando Shift + CTRL + tecla de flecha. Para los
lectores de pantalla que no son compatibles con el uso de teclas de flecha para accesos
directos, puedes reemplazarlos con las teclas H J K L. Algunos lectores de pantalla pueden
requerir el uso de CTRL junto con la tecla alt.
Play video starting at 1 second and follow transcript0:01
In this video, we will discuss users and groups.
Play video starting at 6 seconds and follow transcript0:06
We will start by discussing adding users.

Play video starting at 11 seconds and follow transcript0:11

If you navigate to a Project settings and 
select People, you can use the Add people button to add users to the project. 
The user has to already have an account on your site for 
them to be automatically added. 
Here we try to add a user named Some User to the project. 
Since this user doesn't exist, Jira won't let you add the user to the project.

Play video starting at 34 seconds and follow transcript0:34

In this case, you can enter an email address to invite a user to your site.

Play video starting at 39 seconds and follow transcript0:39

The invited user would then receive an email and 
is given the option to join your site.

Play video starting at 45 seconds and follow transcript0:45

This ability to invite users right from Project settings 
is available if you are a site administrator or 
if the site has been setup so that users can invite other users.

Play video starting at 56 seconds and follow transcript0:56

In this example, we are a user who is a project administrator, but 
is not a site administrator. 
We are trying to add a user who doesn't exist on the site.

Play video starting at 1 minute 6 seconds and follow transcript1:06

We are notified that only site administrators can invite users, and 
that the site administrator can can change a setting so 
that you can invite users directly. 
We will see this setting in a few moments.

Play video starting at 1 minute 20 seconds and follow transcript1:20

Another way to invite users to your site, if you are a site administrator, is to 
click on the Switch to icon in the global sidebar and select Site administration. 
Since you own your Jira account, you are automatically a site administrator. 
Notice that the Jira logo has changed to the Adlasien/ logo. 
We are in site administration. 
If we select the Users tab, we can invite new users.

Play video starting at 1 minute 48 seconds and follow transcript1:48

You specify their name and email address then click Invite users.

Play video starting at 1 minute 55 seconds and follow transcript1:55

Another way to access site administration is from Jira settings. 
If you click on User Management, you will be taken to site administration because 
Jira leverages the user management of the site.

Play video starting at 2 minutes 9 seconds and follow transcript2:09

When a user is invited to the site they're emailed an invitation. 
If they accept the invitation, they become a member of the site.

Play video starting at 2 minutes 20 seconds and follow transcript2:20

Once the user has accepted your invitation, they can log into Jira. 
Here, we have created a test user, 
notice that this user can see the recent activity in the projects. 
They can also access the existing projects and create issues.

Play video starting at 2 minutes 36 seconds and follow transcript2:36

Also notice that there is no Jira settings icon. 
This user does not have the permission to view or change settings.

Play video starting at 2 minutes 48 seconds and follow transcript2:48

We have seen that as the site owner, you can access site administration and 
invite other users. 
If you click on the Site Access tab, you can configure the site so 
that it's easier to have other users join.

Play video starting at 3 minutes 2 seconds and follow transcript3:02

If you check the users can invite others box, project administrators of 
the site can invite other users which reduces your administrative work.

Play video starting at 3 minutes 12 seconds and follow transcript3:12

This means that project administrators can invite users under the People tab for 
the project. 
If you change the WHO CAN JOIN YOUR SITE radio button to the second option, then 
anyone from the email domains that you specify can join without an invitation. 
If you select the Anyone can join option, 
then all domains can join without an invitation. 
You can check this box to get an email notification when a new user get access to 
the site.

Play video starting at 3 minutes 42 seconds and follow transcript3:42

Next, we will discuss groups and product access.

Play video starting at 3 minutes 48 seconds and follow transcript3:48

A group is a collection of users that are treated similarly with respect to what 
they can do on the site. 
If you click on the Groups tab under Site Administration, 
we see the groups that are already set up in your account. 
Groups can be given access to a product and/or 
be given the ability to administer the product. 
These capabilities are only provided through a group membership. 
Access to applications is shown in the center column. 
Notice that by default, 
members of the Jira administrators group do not have access to the issues of Jira. 
If there's a user in this group who needs access to the Jira application, they must 
belong to another group that provides this access such as the administrators group. 
The administrators group is similar to the Jira administrators group, but 
includes access to the issues in Jira.

Play video starting at 4 minutes 38 seconds and follow transcript4:38

The column on the right is used to enable members of 
a group to administer the product. 
You can see that members of the jira-software-users group 
are not given access to administer Jira. 
This is the default group meaning that new users are automatically 
added to this group. 
Users in this group have access to the issues in Jira, but 
do not see the Jira settings icon. 
When you signed up for Jira account, you became a member of the site admins group. 
This group contains users who have access to all applications on this site. 
Their administration features, and to this site administration capability. 
You can click on a group name to manage it.

Play video starting at 5 minutes 19 seconds and follow transcript5:19

Here we are viewing the site-admins group. 
On your account, you should be listed in this group. 
To the right, you can see the access that members of the group have. 
In this example, 
this group has been provided access to Jira as well as admin access to Jira. 
Depending on the group, you can use the buttons in the upper right to add members, 
edit the group description, or delete the group.

Play video starting at 5 minutes 44 seconds and follow transcript5:44

If you click on the Product Access tab, 
you can see the users that have access to applications. 
This green shows how many licences you are currently using. 
Here we can see that we are using two licenses. 
You can see some system users that do not count towards your usage.

Play video starting at 6 minutes 2 seconds and follow transcript6:02

You can revoke a users access by clicking on the Revoke button 
next to their account. 
You can grant access to the application using the Grant access button. 
You can click on the View Configuration button to view and 
change the access given to groups.

Play video starting at 6 minutes 19 seconds and follow transcript6:19

Here we have clicked on View Configuration to see the access given to the groups. 
All of the groups under the Jira software category are provided 
access to the Jira application. 
You can see that the Jira software users group is the default group. 
You can change this by clicking on ,Make this a default group.

Play video starting at 6 minutes 39 seconds and follow transcript6:39

If create a group that needs Jira access, you can click the Add Group button. 
All of the groups under the Jira administration heading are provided 
access to the administration features of Jira. 
You can also add groups to this list by clicking on Add group.

Play video starting at 6 minutes 58 seconds and follow transcript6:58

If you want to create a group, select on Groups tab and 
click the Create Group button in the upper right.

Play video starting at 7 minutes 6 seconds and follow transcript7:06

When you create a group, you create a name and an optional description. 
Here we have created a group named Jira-software-users-external 
with a description that these are users external to our company.

Play video starting at 7 minutes 20 seconds and follow transcript7:20

Now our external group is included in our site, notice that this group does not 
have access to the Jira application or it's administrations features. 
This means that users in this group cannot log in into Jira unless they belong to 
another group that has access.

Play video starting at 7 minutes 37 seconds and follow transcript7:37

To provide access to this group, you start by clicking the Product Access tab.

Play video starting at 7 minutes 44 seconds and follow transcript7:44

You then click the View Configuration button, you then click on 
the Add group button under Jira Software and enter the group name.

Play video starting at 7 minutes 54 seconds and follow transcript7:54

You then click on Grant Access to allow members of the group to access Jira.

Play video starting at 8 minutes 0 seconds and follow transcript8:00

Back on the Groups page you can now see that our new group 
has been granted access to Jira.

Play video starting at 8 minutes 7 seconds and follow transcript8:07

Here's a review of what we've discussed in this video.

Play video starting at 8 minutes 12 seconds and follow transcript8:12

Users can be invited to a site in the Project settings > People tab 
of a project if the logged in user is a site administrator, or 
the site administrator has enabled the Users can invite others option.

Play video starting at 8 minutes 27 seconds and follow transcript8:27

Site administration is used to manage users and groups.

Play video starting at 8 minutes 32 seconds and follow transcript8:32

Groups can be provided product usage and administration access.

Play video starting at 8 minutes 38 seconds and follow transcript8:38

Now, it's time for 
you to work with some of the things that we've discussed in this video. 
Separate hands-on instructions are provided for you.

VIDEO 20

(optional) Permissions

Reproducir video
reproducir
Volumen
0:00/17:45
Ajustes
Pantalla completa
Notas

Todas las notas

Haz clic en el botón Guardar nota cuando desees capturar una pantalla. También puedes
resaltar y guardar líneas de la siguiente transcripción. Añade tus propias notas a lo que hayas
capturado.

Guardar nota
Discutir
Descargar
Ayúdanos a traducir

Transcripción interactiva: para habilitar el modo de transcripción básico, presiona la tecla de escape
Puedes navegar a través de la transcripción usando la pestaña. Para guardar una nota para
una sección de texto, presiona CTRL + S. Para expandir tu selección, puedes usar CTRL + la
tecla de flecha. Puedes contratar tu selección usando Shift + CTRL + tecla de flecha. Para los
lectores de pantalla que no son compatibles con el uso de teclas de flecha para accesos
directos, puedes reemplazarlos con las teclas H J K L. Algunos lectores de pantalla pueden
requerir el uso de CTRL junto con la tecla alt.
Play video starting at 0 seconds and follow transcript0:00
In this video we will discuss Permissions. 
We will start by discussing Global permissions. 
Jira's Permission Model works by granting permission to users. 
If a user can see or do something, 
that means that the user has been granted that permission. 
For example, the difference between a standard user and 
a Jira administrator is that the standard user 
has not been granted the administer Jira permission. 
Managing users and groups, application access, 
and administration access applied to the entire site. 
Now we will move to the Jira application level of the interface. 
We will discuss Jira's Global Permissions which 
define what a user can see and do in the Jira account. 
There are six Jira Global Permissions. 
Administer Jira allows users to create and administer projects 
and perform most administration tasks except for managing users, 
importing, and exporting data, 
and editing system email settings. 
Browse users and groups allows users to see the names of users and groups on the site. 
Share dashboards and filters allows queries to be shared as dashboards and filters. 
Manage group filters subscriptions lets you create and delete group filter subcriptions. 
Make bulk changes allows a user to modify multiple issues in one step. 
Create next-gen projects is a relatively new permission. 
Users can create next-generation 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. 
If an organization wanted to control next-generation project creation, 
they could limit this global permission to only certain groups. 
To view and manage global permissions, 
navigate to Jira's settings, 
select the system tab, 
and then select global permissions. 
On the left, we see the list of permissions. 
On the right, you can view the groups that have the associated global permission. 
You can click on the view users links to 
navigate to the group's tab of site administration. 
The administer Jira permission is unique in that 
even though it is shown on the global permission's page, 
it is managed by providing a group access to Jira administration. 
When you click on a link to configure permissions in user management, 
you are brought to the application access configuration page of site administration. 
We saw this earlier in site management under the product access tab. 
If you add a group to the Jira administration section of this page, 
it will automatically appear in the list of groups 
for the administer Jira global permission. 
Jira also adds the system administrators and Atlassian add-ons admin groups to this list. 
These are basically internal groups managed by Jira. 
Notice that the only group that currently does not have 
the administer Jira global permission is the Jira software users group. 
We have seen that new users are added to this group by default. 
Let's compare the list of groups with administer 
Jira global permission to the list with browse users and groups permission. 
All of the groups that can administer Jira can also browse users and groups. 
In addition, members of the Jira software users group can browse users and groups. 
This enables team members to select from 
other users and groups when using the application. 
If for some reason we did not want members of this group to have this permission, 
we can click the delete link associated with the group. 
Notice that our new external group that we created earlier is not in this list. 
New groups are not given this permission unless you explicitly add it. 
To add a global permission to a group, 
you scroll down to the Add Permission heading. 
You then select the permission that you want to add. 
In our case, we want to add Browse users and groups for our new external group. 
Notice that administered Jira is not in this list. 
This is because that permission is managed using 
the site administration as previously mentioned. 
In the group drop down, 
notice that the first option is anyone. 
If you select this, 
users in any group will have the associated global permission. 
We will select our new external group to 
provide it the browse users and groups permission. 
Now you can see that the external group has Browse users and groups global permission. 
Next, we will discuss next-generation project permissions. 
So far, we have discussed access and permissions that 
apply sitewide and at the Jira application level. 
Project permission specify what a user can see and do in a particular project. 
When talking about project permissions, 
it's useful to differentiate 
next-generation project permissions from classic project permissions. 
Classic project permissions are in general more 
flexible and powerful than next-generation project permissions, 
which are designed with simplicity in mind. 
Next-generation projects allow you to specify 
one of three access settings for the project, 
which we will see in a moment. 
These three options are good enough for a large percentage of projects. 
The permissions for classic projects are specified by a Jira administrator. 
This allows your organization to use common permission strategies for all projects. 
The permissions on these projects can be finally tuned to what your organization needs. 
To access setting for a next generation project is set by a project administrator. 
This allows each team to control their projects permissions. 
When you create a next-generation project, 
you must specify the projects access. 
There are three simple options. 
Open allows anyone with access to your site to create and edit issues in the project. 
This means that the project team members don't have to be separately 
added to the project because they already have access. 
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 your organization. 
If you want to change the access after creating a next-generation project, 
you can navigate to 
Project Settings details and use the access drop down to change the access. 
To add team members to a project, 
you click on Project Settings and then the People tab, 
you then click the Add People button. 
You can add individual users or groups. 
When adding a person to a project, 
you must choose a project role for the user. 
Each role enables different functionality in Jira. 
Specifying the administrator role for a user means that they are a project administrator. 
This user will see 
the Project Settings tab and can make changes to the settings of the project. 
The member role is assigned to the typical member of the project. 
This user does not see the Project Settings tab, 
but they can view, 
add, and edit issues. 
The viewer role is the most limited. 
These users can view and comment on issues in the project, 
but not much else. 
If the project has open access, 
you will see an entry on the People page of the project saying 
that anyone with access to the site has a role of member. 
You do not need to specifically add members to this project. 
Also adding a person or group with a role of viewer would not make 
sense because all users already have a role of member, 
and therefore the user's member role would enable them to add and edit issues. 
Adding a viewer role for users or groups would have 
no effect because if a user is assigned multiple roles in a project, 
the most permissive role wins. 
If the access for a project is set to limited, 
you will see an entry on the projects people page that specifies 
that anyone with access to the site has a role of viewer. 
This means that if you want a user to be able to add and edit issues, 
you must click add people, 
add the user or group, 
and assign them a role of member. 
Also it would not make sense to add a user or group to this project and specify 
a role of viewer because all users of the site are already viewers in this project. 
If a project's access is set to Private, 
it means that none of the users of the site can see, add, 
or edit issues of the project unless they are added to the project's People page. 
For example, if you want a user or a group to be able 
to only view and comment on issues of the project, 
you'd add them with the role of viewer.

Play video starting at 9 minutes 46 seconds and follow transcript9:46

You can view the Jira documentation to see 
the project and issue permissions for each role. 
For example, only users with the administer role can view and change project settings. 
As another example, users with the role of viewer cannot create and edit issues.

Play video starting at 10 minutes 5 seconds and follow transcript10:05

Next, we will discuss an overview of Classic project permissions. 
The classic project permission model contains multiple abstractions, 
so there's more to learn than with next generation project permissions. 
The abstractions in the classic model are done for flexibility, 
and to avoid hard coding user and group names which would quickly become unmanageable. 
The classic project permissions model allows you to use 
custom permissions related policies in your account, 
possibly modifying your policies over time. 
The project role names for classic projects are slightly 
different than the next generation project role names that we saw earlier. 
Jira classic projects have two main built-in project roles. 
The first is the administrators role which is 
analogous to the administrator next generation role. 
This role is assigned to project administrators, 
and grant them the administer projects project permission. 
The other main project role is developers. 
These are the team members who do the work of the project. 
This is analogous to the member role in next generation projects. 
In addition to the built-in roles, 
Classic project roles can be 
created You assign project rolls under the people tab of a project's settings. 
Here we clicked the add button to add our test user to a project. 
We could also add groups to the project. 
You can see that here we must choose between 
the two main default project roles that we discussed earlier. 
Project roles are a Jira application level entity. 
Here we are in Jira settings, 
we select the system tab, 
and then project roles. 
Here are the default project roles; 
we see the administrators and developers project roles that we just discussed. 
There's also a role related to providing project permissions to 
add-ons This enables products that extend Jira to have permissions to do their work. 
Notice that each project role has an associated manage default members link. 
When you create a project, 
Jira automatically will assign any default members to the project role. 
The default members can be users and/or groups. 
Notice that you can add project roles. 
You do this when you want to grant project permissions to certain users for 
a specific set of functionality that is not granted in other roles. 
For example you might add a stake holders project role that allows 
stakeholders to view but not change the issues of the project. 
A permission scheme is used to grant a set of project permissions for a project. 
The permission scheme is what enables flexible fine grained permission control. 
A single permission scheme can be shared by multiple projects. 
Here's an example of a simplified permission scheme 
for a classic project named project A. 
The administer projects, project permission is 
granted to any user with the administrators role. 
In other words any member of the project who has been assigned 
the role of administrators is assigned the administer projects permission. 
To delete issues, project permission is also granted to the administrators role. 
What this means is that normal users who have not been assigned 
the administrators role for the project cannot 
administer the project or delete it's issues. 
To view the permission scheme used for a project, 
navigate to project settings, 
and click the permissions tab. 
This is the permission scheme for project A. 
You can see that this project is using the default software scheme. 
This is the permission scheme that will be used by 
default for all classic Jira software projects. 
Using project roles in the permission scheme means that 
the permission scheme can be re-used for multiple projects, 
this is because there are no hard-coded users or groups The project permissions are 
divided into categories with the first category also called project permissions. 
You can see that the administer projects' project permission 
is assigned to two project roles. 
The first is the administrators role which is for project administrators. 
The second is the add-on role that we talked about earlier. 
If you look at the browse projects' project permission, 
you can see that it is assigned to any logged in user. 
Any logged in user is allowed to see this project, 
and the issues within it. 
This is a key thing to realize about the default permission scheme used in Jira. 
It has an open approach to accessing the projects and 
issues in the account because the browse projects, 
project permission has been granted to any user with Jira access, 
all users can see this project as well as browse the issues within it. 
If for whatever reason your organization doesn't 
want to provide that much access to the project, 
if you are a Jira administrator, 
you can copy the default software scheme, 
and modify it for your needs. 
You would then assign your newly created permission scheme to the project. 
A user who is granted the administer projects' project permission, 
is known as a project administrator. 
In the Jira user interface, 
a project administrator can do more than a typical team member. 
These capabilities are built into the Jira application, 
and are available to project administrators because they had been 
granted the administer projects permission for the project. 
They can manage the members of the project, 
they can manage components which are a way to group a subset of issues in a project, 
they can manage versions, 
edit some project details such as the project name and description, 
create boards, and define 
issue level security which allows them to increase the security of issues in the project. 
We have seen that users who are assigned 
the administrators role are granted the administer projects permission, 
our project administrators, and can perform the tasks just mentioned. 
In addition, the default permission scheme grants 
users in the administrator's role the following 
capabilities: Users assigned the administrators project role can delete issues, 
modify reporters which means that they can change 
the user who created the issue, manage watchers, 
which means that they can change which users are notified when issues change, 
they can edit and delete comments related to an issue. 
A normal user can only edit or delete their own comments, 
they can delete attachments that users made to the issue, 
and they can edit or delete work logs which 
allow users to log their time spent on an issue. 
This is just the default behavior. 
You can create a permission scheme for your project or set of 
projects that customizes these permissions in a way that works for you. 
Here's a review of what we've discussed in 
this video: Jira global permissions apply to all projects, 
and are granted to users and groups. 
Next generation projects have a simple permission model 
with access levels of open, limited or private. 
Classic projects have a flexible permission model, 
with project permissions granted using permission schemes. 
Project roles enables certain product functionality for its members.