Modulo 3

VIDEO 12
This video discusses Quick Search and Basic Search.

We will start with a searching overview.
There are several topics related to searching in Jira.
We will discuss them quickly now and then discuss
them in more detail in this and the next video.
The first is called quick search.
This is accessed by clicking the search icon in the global sidebar.
This allows you to quickly search for text in issues, board names,
project names and filter names using a text-based search.
You can also quickly access recently used items as shown here.
The star is another way to access recently used and favorite items.
Another type of search is called basic search.
This is accessed on
the application level contextual sidebar in the issues and filters tab.
This is called the issue navigator.
In a basic search,
issues are searched for using a row of user-friendly interface elements as shown here.
Changes to these elements will change the resulting list of issues.
Advanced search is an alternative to basic search where you can
specify your search using Jira query language or JQL.
This is a way to execute more complicated searches than with basic search.
Filters are used to limit the issues that are displayed in search results.
You can see filters in the application level contextual sidebar as shown here.
These are the default filters provided by Jira.
For example, if you click on the "Open issues" filter,
the results will show all issues in all projects that have not been closed.
You can also add custom filters such as the filter called my custom filter here.
Even though filters are usually presented as user interface elements,
they have an underlying JQL statement associated with them.
That JQL statement defines which issues to show.
In addition to the application level issue navigator,
there are project level filters shown in the projects contextual sidebar as shown here.
These are used to limit which issues from that project to show.
The final search topic that we will discuss is quick filters.
Quick filters are used to limit which issues are shown on a board.
Here are two out of the box quick filters used to
show only your issues or recently updated issues.
You can also add custom quick filters to the board.
Like standard filters, quick filters have
an underlying JQL statement associated with them.
We are discussing searching JQL and filters because they
are used to help adapt to your Jira experience to your team's processes.
We have seen that each Agile team is unique and constantly improving.
So, the tools that are used need to be
flexible enough to adapt to changing circumstances.
Next, we will discuss quick search.
Quick search is accessible using the icon in the global sidebar.
When you initially open the quick search,
the results show recent items.
You can click on an item to display it.
Typing into the quick search box changes the results from
recent items to items that match the text that you are searching for.
As you type in the search box,
the results are updated.
Here you can see that there are two issues with the field value of feature two.
Searches in Jira are generally not case sensitive.
The quick search does not return just issues.
When you open quick search,
you can also access recent boards, projects, and filters.
When you perform a search,
all of these items that match will be displayed.
Usually, you will just be entering simple text when searching with quick search.
You also have the option of adding slightly more sophisticated syntax.
As an example, on the left we are searching for the text feature.
You can see that this text is in the summary for six issues in our Jira account.
We can exclude feature one by adding a capitalized not followed by the number one.
You can see that the two issues containing feature one are excluded from the results.
In the search, not must be in all caps.
The search terms are not case sensitive but text field search keywords such as;
not, or and and must be capitalized.
In this example, we use the OR keyword to search for a feature or a sample.
For more information on this type of searching,
see the link shown here on search syntax for text fields.
If you include multiple terms in the search,
the default is to combine them with "and".
You can see that if we search for feature one,
we receive the same results as if we search for feature, AND 1.
You can use the wildcard character which is
an asterisk in text field searches to match parts of words.
Next, we will discuss basic search.
Basic search uses user-friendly interface elements
in the "Issue" navigator to search for issues.
This row of elements shows that we are in the basic search.
We can click on the "Advanced" link to switch to the advanced search.
Likewise, if we are in the advanced search,
we can click on the basic link to switch to basic search.
You can see that this search searches all projects for issues of any type,
in any status and with any assignee.
This is searching for all issues in the Jira account.
You can see that there are currently 29 issues in this account,
assuming that we have permission to see all issues.
If we click on the "Project" drop-down and choose
"projectA" you can see that three issues are returned.
Notice that basic search includes a text box with the words "Contains text".
This behaves much like the quick search but is limited to searching issues.
If you enter text in this text box,
Jira will search in fields that typically hold texts such as summary or description.
In this example, we have changed the project drop-down to
projectA and added "feature NOT 1" to the contains text box.
This will filter the "Add feature 1" issue from
the project and you can see that we are left with two issues.
You can see that the capital "NOT" in the quick search can also be used here.
If you type text into the quick search box,
the search results are immediately updated as shown.
Here we have typed "feature NOT 1" into the quick search box.
If you press the "Enter" key after typing in the search text,
you will be brought to the issue navigator with your text already entered in the search.
The resulting issues match the issues from the quick search.
As a simpler way to enter the issue navigator,
you can open the "Quick Search" and simply press "Enter".
If you want to search for values and fields that are not listed in basic search,
you can click on the "More" drop-down to add searches for other fields.
We will click on the updated date checkbox to add
a search related to the day that an issue was modified.
Here we have clicked on "Updated date" and you can see that Jira
adds a dialog allowing you to specify the date values to search for.
We have chosen to search for any issues that have
been updated within the last three days.
Adding the search for the updated date,
reduced the results to the three issues shown here.
We can click on the "More" drop-down to add additional search criteria if we would like.
Here, we have selected "Priority" from the "More" drop-down menu.
Notice that Jira will automatically provide
the appropriate interface depending on the type of field chosen.
We have just seen that when we selected the "Update date" field,
we were provided an interface related to dates.
In this case, we have selected the "Priority" field so
Jira provides us a set of priorities to choose from.
Next, we will discuss working with search results.
The icon shown here is the "Change view" icon.
There are two modes for the view of the search results.
The first is "List view", which we see here.
If we change the view to the "Detail view",
we see a list of search results on the left,
along with the details of the currently selected issue on the right.
In list view, you can select the columns drop-down and pick
and choose which columns that you want to display in your search results.
To rearrange the columns in the search results of list view,
you can click on the column heading and drag the heading to the new location.
To sort the search results by column,
click on the column that you'd like to sort by.
In this example, we've clicked on the "Updated" column.
The downward facing arrow means that the items will be displayed in descending order.
In this case, it means that the issues in the search results are
sorted with the most recently updated issues first.
You can click on the "Updated" column header again to change the arrow to upward facing.
Meaning that the most recently updated issues will be at the bottom of the list.
If you have search results that you would like to share with another member of the team,
you can click on the "Share this search" icon in the upper right
and specify the user or users that you'd like to share the search with.
This will email a link to the project that includes the underlying JQL for the search.
When the user clicks on the link in their email,
their browser will open with the search results.
The query will be executed again,
so the results might look different from when you originally performed the search.
You can export the search results by clicking on the "Export" icon in the upper right.
You have a variety of export options to choose from.
We will export the search results as XML as an example.
When you export the search results as XML,
the XML opens in a browser window and maybe downloaded to your computer.
This contains the field names and values for the issues of the search results.
Besides a handy backup,
this is a way to see what the actual field names and values are for an issue,
providing you a better understanding of how Jira defines an issue.
You can click on the "More Options" icon in the upper right.
You can change all of the resulting issues at once by selecting the "Bulk change" option.
For example, if someone has left the team,
you could bulk assign all of that person's issues to another user.
In more options, you also have the ability to
import issues from a saved comma separated value document.
Here is a review of what we've discussed in this video.
Quick search is accessible from the global sidebar and searches the text of issues,
board names, project names and filter names.
Basic search is a user friendly way to search for
issues and is accessible from the issue navigator.
Search results can be reordered,
exported and used to bulk change issues.
Now, it's time for you to work on the things discussed in this video.
Separate hands-on instructions are provided for you.
VIDEO 13
JQL
In this video, we will discuss JQL.
We will start with a JQL overview.
Play video starting at 10 seconds and follow transcript0:10
In the previous video,
we explored basic search.
In this example, we are searching for all issues that we have permission to view in
the Jira account because none of the search elements are being selective.
On the basic search,
there is an advanced link which allows
you to switch to the advanced mode of searching for issues.
Here is advanced search.
Jira will automatically populate the text box with
a text-based equivalent for the current basic search.
This text says, order by created descending.
In other words, search for all issues in
this Jira account and sort the resulting list by the value of the created field.
The created field holds the time and date that the issue was created.
Descending means to show the newest issue at the top
of the resulting list and the oldest issue at the bottom.
You can click the basic link to switch back to the basic search.
That text that we saw in the advanced issue search is called Jira Query Language or JQL.
JQL uses a Structured Query Language like syntax.
A Structured Query Language is commonly called SQL or SEQUEL.
This is used to search databases.
JQL is used to search issues only.
This is why the JQL string can be so simple.
You don't have to enter something like from issue in the query because that is implied.
We have seen that the basic search contains
user-friendly interface elements to perform the search.
We have also seen that the queries can be quite complex by
selecting from multiple elements or adding text-based searching.
Advanced search uses JQL and allows for more powerful searches
because it is not limited to the capabilities of
the user interface elements of basic search.
Also, if you are automating anything related to Jira,
you would use JQL because automation relies on text-based scripts.
Whether you are using basic or advanced search,
the JQL related to the search is always there behind the scenes.
The easiest way to write the JQL query is not to write it at all.
You can let Jira write it for you.
Here we are in basic search and select projectA from the drop-down.
We can see that projectA has three issues.
We can then click on the advanced linked to enter the advanced search.
The search results don't change at all,
but the query is displayed instead of the basic search user interface.
That query displays all of the issues with the project key of PROJ.
The results are ordered by the date that the issue was created.
JQL queries can fundamentally do two things,
and we see both of them in the query that was just created.
They can select a subset of issues as we see in the first part of the query.
We are selecting only issues in which the project field has a value of PROJ.
They can sort the results using an order by clause.
We are ordering the results by the date that they were created.
Next, we will discuss autocomplete.
We have the option of creating a JQL query from scratch.
Let's create a query that searches for the issues in a project.
Project is a field name in the Jira issue,
and each issue is assigned to a single project.
In the advanced search text box,
we can begin typing PR,
and Jira will help us with autocomplete suggestions.
Autocomplete will show up to 15 matches.
This makes writing JQL much easier and helps avoid mistakes.
In this case, we select the project field as the start to the query.
Notice that there is a syntax help option at the bottom of the list.
This will point you to the documentation for advanced search.
When we have entered project in the search box and hit the space bar,
Jira provides a list of choices of what should be next in the query.
This list contains what are called operators.
Since we are looking for issues in a particular project,
we select the equals operator.
When you press the space bar after entering the equals operator,
Jira again provides you with a list of choices.
We can see that this Jira account has three projects that we have permission
to see and we can select a project name to view its issues.
When we complete the query and click enter,
the search is performed.
Here we can see that there are three issues in projectA.
At this point, if we click on the basic link,
we can see that projectA is selected in the drop-down list.
This is equivalent to the JQL that we just created.
If we click on the updated column in the search results,
we can see that the results are sorted and we can see that
our query has been updated with an order by clause.
This is very helpful when creating JQL queries.
You can create a search in basic search,
change the output to be sorted the way that you would like,
and then copy the query that Jira has created.
You usually don't have to create queries from scratch.
In the previous example,
we knew that we were searching for the project field.
If you are unsure of which field to search for or to get
more information related to the field such as supported operators and functions,
search the web for the advanced searching fields reference documentation from Atlassian.
Next, we will discuss order by.
The simplest JQL is an empty string as shown here.
This means that we are not being selective about which issues that we see,
so we see them all.
You can see that there are 29 issues in this Jira account
assuming that the current user has permission to see all of the issues.
We don't specify how we would like the results to be ordered.
So, Jira picks the default ordering.
It looks like the default ordering is by the issue key in a descending order.
Order by in a JQL query is used to specify the order of the results.
In the simple case of an empty string is a query,
as we see on the left,
all of the issues are displayed in the default order.
We guessed that the default sorting is by issue key in a descending order.
On the right, we verify that guess by
specifically adding an order by clause to the query.
You can see that if we specify order by key descending,
we get the same results as we did with the empty query.
The only real difference is that on the right,
you see a descending arrow on the key column header.
If you click on the "All issues" link in the Issue Navigator,
you can see that the query is simply an ORDER BY clause.
The results are ordered by the date and time that the issue was created,
starting with the most recently created issue.
You can also see that the created column header has a descending arrow.
Clicking on any column header will change the ORDER BY clause in the query.
You can add multiple field names to the ORDER BY clause by separating them with commas.
The first field name is the primary sorting field,
and any other fields take effect only if
the prior field had multiple values that were exactly the same.
In this example, we are sorting primarily by
the summary field because it is first in the ORDER BY clause,
and because you can see that the summary column has the sorting arrow.
We have multiple issues with the exact same summary,
so the secondary field of the issue key is used to sort those matches.
In this case, the PRJ-1 key is alphabetically before the PROJ-1 key.
As you click on multiple columns in the search results,
you will notice that more fields are added to the ORDER BY clause.
The first field is by far the most important one.
Next, we will discuss functions.
Play video starting at 8 minutes 27 seconds and follow transcript8:27
You usually only want to return a subset of issues from a search.
An issue selection clause is used to limit
or filter the issues that are returned in the results.
The basic structure of the clause is a field name,
followed by an operator,
followed by a field value.
We have seen an example where we are selecting
all issues that have a project field value of projectA.
Instead of directly providing a field value and the issue selection clause,
you can provide a function.
A function is a small program that JIRA calls before the query is executed.
The result of calling the function is then substituted in the query.
As an example, this clause will search for issues that
have been assigned to the currently logged in JIRA user.
A big advantage of using functions is that,
you are not hard coding information,
this same query can be used by all users to view their issues.
The JIRA advanced searching functions are documented,
so that you can use them if and when you need them,
do a search for advanced searching functions reference to find it on Atlassian website.
You can then find the details related to any functions that interest you.
Here's a list of the advanced search functions that are related to time and date.
There are functions that specify the start of a time period,
and the end of a time period.
The "now" function represents the current time.
The current login function results in the time that the current user logged into
the session and the last login function
results in the time that the current user logged into the previous session.
As an example, this query will find issues created since the start of today.
If the field is related to dates,
you can add what's called a Time Unit Qualifier
to specify relative dates as field values.
This is a specially formatted string that JIRA will
replace with an actual date value before running the query.
In this example, we are searching for issues created in the last two days.
The Time Unit Qualifier is handy,
because it is simple,
and the query doesn't have a hard-coded date.
This line shows the syntax that can be used to specify time units.
It starts with a plus sign,
a vertical bar and a minus sign in parentheses.
The parentheses mean that,
what is inside is optional.
The vertical bar means or.
If you add a minus sign to the string,
you are searching back in time.
Using the plus sign or leaving off the sign altogether,
means that you are searching forward in time.
You can see that, this query uses the minus sign,
so this query is searching for issues that were created two days ago or later.
The "nn" in the string represents numeric digits.
In this string, the numeric digit is two.
Following the numeric digits is the optional time period unit.
You can specify y for year,
capital M for month,
w for weak, d for day,
h for hour and lowercase m for a minute.
In this case, we specify d,
so this query is searching for issues created within the last two days.
We could change that d to a w for example,
to search for issues that were created in the past two weeks.
If you leave off the units,
JIRA will assume a logical default unit,
which depends on the circumstances.
You can also use Time Unit Qualifiers as arguments to a function.
An argument is a value that is passed to functions to change its behavior.
If the trailing parentheses of the function call are empty,
you are not passing any arguments,
and the function is called with its default behavior.
In this example, we are adding an argument to change the function,
so that we are searching for issues created since the start day two days ago.
If today's Wednesday, this would be searching for issues created on Monday or later.
Here's an example of finding issues created since the 15th of this month,
assuming we are currently in the second half of the month.
Notice that, the function is related to months,
but we're passing an argument related to days.
The time periods do not need to match.
Next, we will discuss operators.
An operator is placed between the field name and the value.
In this example, the operator is the equal sign.
You can use autocomplete to see
which operators that you can use for a specific field name.
In this example, we have entered the project field name,
and then press the space bar.
Autocomplete provides a list of choices for the operators.
In this example, we have entered the summary, field name and then press the space bar.
Notice that JIRA provides a different list of operators for the summary field.
For example, the project field accepts the equal sign as an operator,
and the summary field accepts the contains operator,
which is represented by a tilde.
JIRA's autocomplete provides the acceptable operators
based on the expected type of field value.
The project field expects a project name,
and the summary field expects a free-form of text.
The advanced searching-operators reference documents the details related to operators.
We will briefly go over operators in this video,
but this is mostly to provide you awareness of
what is possible with operators and queries.
The operators reference is very helpful as you are writing queries.
The equals operator will find issues,
where the field value exactly matches the value in the query.
This query will find all issues in projectA.
The "not equals" operator represented by an exclamation point before the equal sign,
finds issues where the field value does not exactly match the value in the query.
This query finds all issues that are not in the projectA project.
Some fields allow the greater than,
greater than or equal,
less than and less than or equals operators.
For example, these are commonly used along with fields that expect values of dates.
This query finds issues created today.
This query uses the greater than or equals
operator to find issues with three or more story points.
Notice that we have to surround the field name in quotes because it contains a space.
This query finds issues created more than a week ago.
This query finds issues with three or less story points.
The in and not in operators are used with a comma separated list of values in the query.
This query finds issues that are either in projectA or in projectB.
Notice that there are parentheses around the set of
values and the values are separated using commas.
This query finds issues that are not in projectA or projectB.
The is and is not operators are very limited in what they do.
They are used to determine if a value has been set for a field.
These operators can only be followed by one of two values, empty or null.
Both values are keywords in JQL.
They mean the same thing.
In this example, we find issues that have no assigning.
We do this first using the is operator,
which is equivalent to the equals operator.
In this example, we find issues that have an assignee using the is not operator.
This query is equivalent to a query that uses the not equals operator.
The contains and does not contain operators are used with text fields only.
Text fields include summary, description,
environment, comments, and any custom text fields.
In this example, our field is summary,
and since it's a text field,
the contains and does not contain operators are offered as options.
This query finds issues in which the summary field has a value of feature one.
We put quotes around the value because values with spaces must be surrounded by quotes.
This query finds all issues where the summary does not contain the word feature.
Quotes are not required because this is a single string of simple text.
You can perform a search that is similar to the global search
using the special name of text and the contains operator.
In this example, the query is for any text field that contains feature, but NOT 2.
You can see that you can use
the same text query syntax that we discussed for quick search earlier.
Note that the capital NOT inside the string is case sensitive.
A lowercase NOT is a reserved word and is ignored in the search.
The keywords in these text fields searches are an exception to
the general rule that Jira searches are case insensitive.
The was and was not operators are used to find issues that previously had a value.
Since Jira keeps a historic record of events and
values that history can be searched using these operators.
In this example, we find issues where the current user has been assigned.
In this example, we find issues that have never had a status of In Progress.
The was in and was not in operators are similar to the was and was not operators,
but applied to a set of values rather than a single value.
This query finds issues that had one of two statuses,
either selected for development or in progress.
This query uses the was not in operator to
find issues that have never had one of those two statuses.
The operators with the word was in them can have a predicate appended to the clause.
Predicates are used to narrow the search results from the clause.
Here is the list of predicates for these operators.
The AFTER, BEFORE, DURING,
and ON predicates are used to limit the date range of the query.
The BY predicate is used to specify the user performing the change.
This example finds all issues that were moved to
the Done status by the current user in the past month.
Notice that predicates can be combined as we see here with the BY and AFTER predicates.
The final operator that we will discuss is the changed operator.
This is used to find issues that have a field value that has changed.
For example, this query finds issues
whose assignee has changed since the issue was created.
The change operator also has predicates that can
be added in order to narrow the returned issues.
In addition to the predicates that we saw are related to the was operators,
the changed operator adds FROM and TO predicates.
This example finds issues whose status changed from
Done to In Progress at some point in their history.
Next, we will discuss Boolean operators.
Boolean operators are used to either combine or negate clauses.
The AND and OR Boolean operators are used to combine multiple clauses,
allowing you to refine your search.
For example, this query finds all issues assigned
to the current user with the status of In Progress.
This query finds all issues with the status of Selected for Development or In Progress.
This query is equivalent to using the IN operator.
The NOT operator is used to negate one or more clauses.
For example, this query finds issues that do not have a status of Backlog.
This is equivalent to using the Not Equals operator.
In this example, we find unresolved issues in
all projects except for the sample A project.
Notice that we are combining AND and NOT Boolean operators.
You can do the same with OR and NOT Boolean operators.
If your query has multiple Boolean operators,
use parentheses to set the operator precedence and improve query readability.
In this example, we have added parentheses,
so the OR Boolean operator is evaluated first.
The result is then ended with the first clause.
So, this query searches for all issues with the status of Selected for
Development or to do with the summary containing the text feature.
You can see that this results in two issues.
If we remove the parentheses,
the AND Boolean operator is evaluated first.
In this example, we are searching for issues containing
the text feature with the status of Selected for
Development or any issue that has a status
of To Do because many issues have a status of To Do.
This query results in 13 matching issues.
If your query combines the use of AND and OR Boolean operators,
there are two precedence rules.
Parentheses take precedence, meaning that what
is inside of parentheses is evaluated first.
The AND operator normally has precedence over OR.
This means that if there are no parentheses to set precedence,
the AND operators are evaluated first from left to right.
This is analogous to math where multiplication has precedence over addition,
unless parentheses changed the precedence. Here's an example.
This query contains an OR as well as an AND Boolean operator.
Since there are no parentheses used to change the precedence,
the AND is evaluated first because AND has precedence over OR.
This query is equivalent to the previous query.
Putting parentheses around the AND operator means that AND is evaluated first,
but it already was evaluated first in this query;
so,the queries are equivalent.
A general tip is to use parentheses in
queries with mixed operators to keep things simple and unambiguous.
Here's a review of what we've discussed in this video.
A JQL query is behind all basic and advanced searches.
Leverage basic queries and autocomplete to simplify creating JQL queries.
JQL queries may select subsets of issues and/or order query results.
Functions can be used to avoid hard-coding values in a clause.
Time unit qualifiers can be used with date-related fields.
Allowable operators depend on the type of field value.
Use operator autocomplete to simplify writing clauses.
Boolean operators are used to combine or negate clauses.
Now, it's time for you to work on some of the things that we've discussed in this video.
VIDEO 14
In this video, we will discuss filters.
We will start with an overview of filters.
If you open the application level sidebar and select the issues and filters tab,
you are presented with search related tabs as shown here.
Each of these tabs is a filter.
Filters are saved searches that can be exposed through user interface elements,
filters are a handy way to execute common searches.
If you click on the tab,
the search is executed and you can see the query that was used for the search.
In addition to the default filters that Jira provides,
you can create custom filters such as the My custom filter that was created here.
Saving a search creates a filter,
start by creating and executing a query in
either basic or advanced search then click on the,
"Save as" link to begin the process of saving the filter.
In this example, we have created a search that selects issues that
have a status of in-progress and that the current user owns.
We then click on the, "Save as" link to create the filter.
We will name this filter My in progress.
Once we've created the filter,
it will show in the application level sidebar under the starred category.
Also if you click on,
"View All filters" you can see your newly created filter in the list
along with some filters for project boards which we will discuss later in this video.
By default, the filter is a private filter,
meaning that it's only accessible to you.
You can click on, the "More" icon to the right of
the filter to change metadata related to the filter.
Select Edit filter details to edit it.
On the Edit Current filter screen,
you can change the name of the filter,
add a description, add or remove it from
your favorite filters and share the filter with others.
Here we are sharing the filter with the members of the project 18,
they will see the filter in their sidebar.
Filters are application-wide entities in Jira.
That is why they are configured in the application level sidebar.
The extent to which a filter is visible to users
depends on the extent that they are shared using the screen.
Depending on the permissions of the user creating the filter,
they can choose to keep the filter private shared with
only certain projects or groups of
people or expose the filter to all users of the account.
To edit the query for a filter,
execute the original filters so that you can view the query,
modify and execute the query.
When the query is modified,
you will see the edited indication next to
the filter name and can click the "Save" link to overwrite the existing query.
Next, we will discuss quick filters.
The search box shown above the columns is used to
filter the issue shown on the board using text entry.
In this example, we have searched for the text feature two and
the board only displays the issue with a summary of add feature two.
You can use the assignee drop down to filter the board so that
only issues assigned to a particular team member are shown.
This may especially be helpful in
stand-up meetings where you can discuss your issues with the team.
quick filters are another way to further filter issues displayed on a board.
By default, all the issues are displayed.
You can see that there are two default quick filters.
Check the only My Issues box to limit
the board to displaying issues in which you are the assignee,
check the recently updated checkbox to show
only the issues that have been updated in the last day.
If you have a lot of quick filters,
you can use the search box to find your filter.
Here we only have the default quick filters so the search box is not too helpful.
To edit or add to the quick filters of a board,
navigate the board settings and click on the quick filters tab.
Here you can see the two default quick filters,
the first shows only the current user's issues,
the second shows issues which have been updated in the last day.
You can create a quick filter here specifying the name of
the new quick filter it's JQL and an optional description.
Any filters that you create will be accessible to anyone who can see the board.
To configure the board,
you must be either a project administrator or a board administrator.
Quick filters are only configurable in board settings,
they are not configured like the standard filters that we discussed earlier.
Here we are creating a quick filter that is basically
the opposite of the recently updated filter.
We are selecting issues that are older than
24 hours except if they have a status of done.
Notice that auto-complete works when creating
a quick filter or you can simply paste JQL from somewhere else.
Here we see that are Stale Issues quick filter is available on the board.
It will be seen by all users who have access to the board.
A board's quick filters can also be used to refine reports.
Here we are viewing the cumulative flow diagram report.
If we click on the Refined Report drop down,
we see that we can de-select columns or Swimlanes to hide them from the report,
we will discuss Swimlanes a little later.
We could further filter the issues that are being reported on by
clicking on one or more quick filters to enable it.
They are all not enabled by default.
Here we have enabled the Stale Issues quick filter that we just created.
Be sure to click, "Apply" to see the changes to the report.
Next, we will discuss A board's filter.
In addition to quick filters,
the board itself has a filter associated with it.
This filter is used to determine the issues that are visible on the board.
If you navigate to the general tab of the board settings,
you will see that a filter query is assigned to the board.
The query searches for issues that have this projects' project
key and orders the result of each column by the issues rank field.
Rank is the drag and drop order of
the issues and generally should be included in board filters.
This filter was automatically generated when we created a project with a Kanban template.
The filter for the board has the name filter for PROJ board,
and you can click on the, "Edit Filter Query" link to change it.
When you click on Edit Filter Query for the board,
you are brought to the search window with
a basic or advanced query shown along with the search results.
Here you can edit the board's filter.
For example, you can remove done issues that have not been updated in a month.
Another way to view and edit a board's filter is
to click on the View all filters tab that we saw earlier,
this window will show your Board filters along with your custom filters.
You can see that a board's filter is a standard filter like the ones that we saw earlier.
You usually don't want to star filters for boards
because they don't make much sense in the context than the other filters.
You could star a board's filter if you want to though.
Next, we will discuss creating a board.
In addition to the default boards that are created when you
select Kanban Scrum or agility projects,
you can create other boards.
There are three main steps to creating a board.
The first step is to decide what board to create,
the second step is to create the board's filter,
the third step is to create the board.
The first thing you need to do is decide on the boards location.
The board can belong to a project or can belong to your profile.
If it is part of a project,
the team members for the project can see the board.
If it belongs to your profile,
only you can view the board.
The last step is to create and configure the board so that it can be used.
The first step is to decide on what board to create,
a person or the team needs to have a reason to create
another board rather than just changing the existing board.
There are many reasons to create boards, for example,
you could create a custom version of
an existing board leaving the existing board in place,
you might do this to simplify the board for certain situations.
You could also create a board for a subset of
the statuses of a workflow that might span multiple teams,
a custom board could provide only issues in statuses that matter to a particular team.
You can also create a board that displays issues from multiple projects.
A board's filter can select from any projects in
the Jira account so you could create a board that shows the status of multiple projects.
We will create a board that displays all issues that are
work in progress for project A and project B.
For us, this means any issue that is either in
the selected for development or in progress status,
this board can serve as a report that shows the current work of multiple projects.
Once we have decided on what board to create,
the second step is usually to create the board's filter.
We usually do this before creating a board because when you create a board,
you will be given an option to specify an existing filter.
You can create the filter anyway that you want as we have learned earlier,
it is just the saved search.
One way to create a board's filter is to start by copying an existing one.
Here, we have navigated to issues and filters and selected view all filters.
We will use project A's filter as the starting point,
so we select copy filter from its More menu.
We will name this filter "All WIP issues."
We have created the filter,
it is a private filter but it starred so it
shows up in the starred category in the sidebar.
We might not want that filter to show up in the sidebar,
so we can click on its star to remove the filter.
You can see that the other board filters are also not starred.
Here, we have unstarred our filter and it no longer appears in the sidebar.
Our filter is still just a copy of the filter from project A,
so we click on its link to bring us to the search page.
The query is executed and we are brought to basic or advanced search.
In this case, we are an advanced search and can we can see the JQL.
This is a copy of another projects filter but we can use this as a starting point,
change the query and then save the all WIP issues filter again.
We change the query so that the board's filter does what we wanted to.
In this query, we are looking for issues in project A or project
B and that have a status of selected for development or in progress.
These are the statuses that we consider to be of interest for this board.
We finished the query with the Order By clause that we copied from project A's filter.
This clause orders the results by rank,
which is the drag and drop order of the issues on the board.
Notice that the results contain issues from multiple projects,
also notice that Jira informs us that this query
has been edited and gives us the option to save it.
We click Save to update our filter and we are now ready to create the board.
You have a fundamental choice with where to create a board.
You can create a board as part of a project or you can create the board and your profile.
You can change the location of the board at any time so this decision isn't permanent.
If you choose to create the board in a project,
there are multiple ways to start.
Here, we are in our project A Kanban board.
If we select the board dropped down,
we see the Create board option at the bottom.
Another way to create a board is to click on View all boards in that same dropdown.
The screen like this will open,
showing all of the boards that you have permission to see.
You can click on the Create board link in the upper right to create the board.
Another option for creating a board is under the More menu of an existing board.
Here, we have navigated to our Kanban board.
If we click on the More icon in the upper right,
we can see a Create board item.
You may have seen that option when you configured boards earlier in the course.
The other main option you have to create the board is in your profile.
You access your profile by clicking on
your user icon in the lower left of the screen and selecting Profile.
When you view your profile,
you will notice a section called Boards in your profile.
We currently don't have any boards in our profile,
but we can click on the Create new board link to create a board there.
In our example, we will first create the board
in our profile and later move it under a project.
After you click on Create new board,
you're presented with a choice of the type of board.
We will choose the Kanban board.
You're then presented with another choice,
you can create the board by copying a board from
an existing project or you can create the board from an existing saved filter.
Since we have our boards filter all ready to go,
we select this option.
You are then presented with a nameless board screen.
We will name this board the same as our boards filter, All WIP issues.
We must specify a saved filter for
the board and we select our filter from the dropdown list.
For now, we're keeping this board private and saving it to our profile.
Notice that you can change this board's location to a project here, if you want.
We then click on Create board.
We are then brought to our new board.
You can see that this board belongs to our profile.
The board contains issues from multiple projects.
It's a good start but this board isn't quite right.
We will click on the More icon and select board settings to configure this board.
If we click on the General tab of the board settings,
we can see that our all WIP issues filter is being used for this board.
You can also see the filter query.
If we click on the Columns tab,
we can see how the current board is configured.
We are selecting issues from project A,
which is a Kanban project and from Project B,
which is a Scrum project.
All of the statuses from both projects are added to the board.
We can see that there are only three columns for all of these statuses.
The filter query is shown below to help us configure this board.
Notice that a query only contains the selected for development and in
progress statuses but other statuses such as backlog are shown on the board.
We can start by moving the statuses that we don't care about to the unmapped section.
Here, we have moved the unused statuses to the unmapped section.
We are left with this selected for development and in progress statuses.
They are the statuses used in the board's filter.
If we ever change the board's filter,
we can also change this configuration to match.
Notice that the selected for development status is in a column called To Do.
We will change that to match the status name.
The in-progress status is in a column with the same name,
so that column is okay.
There's a Done column on the board that is not used.
We can click on the Trashcan icon to remove that column from the board.
Here, we have changed the name of the first column to match
the status name and we have deleted the Done column.
We can then begin to use our new board.
Here's our board. We can now see the issues from the selected
for development and in progress statuses for both projects.
This board can function as a report where we can
quickly see what is happening with multiple projects.
Notice that Jira has added a Reports tab.
You may find reports related to issues on this board useful.
If you want to change the location to or from a project,
you can click on the General tab of the board's settings and
specify a project or your profile as the location of the board.
Filters are saved searches that can be exposed through user interface elements.
Quick filters are saved searches that are used to further
limit the issues displayed on a board or in reports.
A board's filter is a query that is used
to determine the issues that are shown on the board.
Boards can be created for projects or for your user profile.
Boards can contain issues from multiple projects.
Now, it's time for you to work with some of
the things that we've discussed in this video.
VIDEO 15
Issue Types
Reproducir video
reproducir
Volumen
0:00/12:57
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 issue types.
We will start with an overview of issue types.

In Jira, an issue is a generic name for a unit of work.

In your projects, there are usually different types of units of work.
The issue type field is used to differentiate these.

When you create an issue, you can choose the issue type.
You can also change the issue type after creating it.
Notice that each type has an associated icon to help
easily identify the issue type.
A story is a requirement from the user's perspective.

A task is a work item that needs to be done by the team, but
is not directly tied to user requirements.
An example might be upgrading the version of a product used by the team.

A bug is a flaw that needs to be fixed in the product.
It can be tracked with its own issue type to differentiate this work from
other types of work.
Play video starting at 1 minute 4 seconds and follow transcript1:04

An epic is a big issue that can contain other issues.

A subtask is a part of another issue.
It is used to break an issue down into specific pieces of work.

When creating an issue, subtask is not shown in the issue
type drop-down because subtasks must have a parent issue.
They cannot be created independently.
In addition to these out of the box issue types, you can create custom issue types.
This provides your team the flexibility to work the way that they want to work.

How the team actually defines what each issue type means is entirely up to them.
Also, different projects can use different issue types.

There are several reasons to use issue types with your projects.

They support different types of work items.
A team usually doesn't have only one type of work, and
issue types allow the team to differentiate those.

Each type can have different fields, screens, and workflows.
For example, you might want bugs to appear at the top of the project's board.

You can also report on issue types separately.
For example,
because the issues of the project have been categorized by issue type,
you can easily create a report with the number of bugs fixed in the previous week.
We will discuss each of these more later.

Next, we will discuss subtasks.

Subtasks are an issue type that must have a parent type.
To create a subtask, you click on the create subtask icon for the parent issue.

Subtasks allow an issue to be broken down into individually manageable tasks.
They can be assigned to different team members.
Subtasks can be more technical than the parent issue.
For example, if the parent issue is a story, the story will be written
in non-technical language that all team members and stakeholders understand.
But the subtasks can be written for the technical person implementing the subtask.

Subtasks have their own issue keys and fields.

Here is a story with two subtasks.
Each subtask has its own issue key and summary field value.

The subtasks have independent workflow statuses and
move through project boards independently.

Since subtasks have their own issue keys and
fields, they can be converted to other types of issues.
To convert a subtask to another type of issue,
view its details, then click on the more icon and select covert to issue.
Converting a subtask to an issue involves a few steps.
The first is to select the new issue type.
Here we are converting a subtask to a task.
You are then prompted to optionally change field values for the issue.

You can also convert other issue types to subtasks.
Click on the more icon for an issue and select convert to subtask.

When converting an issue to a subtask, you must select the parent issue.
You will then be prompted to update the subtasks field, if desired.

Next, we will discuss editing issue types.
Creating and modifying issue types is done for
the project by navigating to the project and then selecting project settings.
This allows you to administer the project.

After navigating to the settings for the project,
click on issue types to view the issue types for the project.

You can see that this project has five issue types.
These are the default types for Kanban projects.

The issue types for
a project are organized into something called an issue type scheme.
Schemes are commonly used behind the scenes in Jira to organize a collection
of related things.

The issue type scheme name includes the project key, in this case, it's PROJ.

You can change this issue type scheme without affecting other projects,
unless some other project decided to use your scheme.

Notice that each issue type can have a unique workflow associated with it.
All of the issue types use the same workflow, so
they will all go through the same statuses.

Each issue type can have unique fields,
allowing you to customize an issue by issue type.
In this case, all of the issue types use the same field configuration, so
the field names are the same for all issue types.

Each issue type can have unique screens.
The screen is a user interface element used to show
fields to users in a context appropriate way.
For each issue type, a screen scheme is used.

Screen schemes are collections of screens.
In this case, all of the issue types use the Kanban default screen scheme,
with the exception of bugs.
The screens for bugs are slightly different than other screens to show
bug related fields that would not normally apply to the other issue types.

To change something related to your issue type scheme, click on actions.
You can see that you have two basic options.
You can edit this issue type scheme, or you can reuse an existing scheme.

As an example, we will click on edit issue types so
that we can make a minor change to the existing issue type scheme.

Before we click on this, notice that we are still in the settings for the project.

Here is the modified issue type scheme screen.
Notice that we have changed from the project settings context
to the settings for the entire Jira application.

This is because issue type schemes can be shared by more than one project.
Play video starting at 7 minutes 1 second and follow transcript7:01

Jira has navigated you to the issue type scheme section and
selected the issue type scheme for your current project.

On this screen, here you can modify the scheme name.
Here you can add a description.
Here you can change the default issue type that is selected when you create an issue.

When we first created issues earlier in the course,
they were stories because of this setting.

Here's the list of issue types for
the current scheme in the order that they would appear in a drop-down list.
You can drag and drop inside of this list to change this order.
If you don't want to use one of the issue types in your project,
you can drag it from the list on the left to the list on the right.
The list on the right contains any issue types that are defined in your Jira
account that are not used by your project.
For example, custom issue types from other projects would appear here.
If you want to add an issue type to your project, click the add issue type button.

Here's the screen that appears when we click the add issue type button.
You can create any issue type that makes sense to your team.
Here we have created an issue type named Small.
This might be created because the team has a policy that all work must be tracked in
Jira, even items that take a small amount of time to complete.
This differentiates this type of work from bigger issues,
allowing you to report on them only if necessary.

For example, you can exclude these from accumulated flow diagram.
When adding an issue type,
you have the option of creating it as a standalone issue type or a subtask.
If you select subtask, this issue type must have a parent issue.
You could not create them independently.

Once we have added an issue type, it appears in the list of issue types for
the project.

We could change the order of appearance by dragging it to a different location
in the list.
When you're happy with the changes to the issue type scheme, click save.

After modifying the issue type scheme,
Jira brings us back to the settings context for our project.
Our issue type scheme now shows the added issue type.
Notice that our issue type has been given an icon.
It also has been assigned the same workflow, field configuration, and
screen as most of the other issue types in the project.
Any of these can be changed.
Next, we will show how to change the icon for a new issue type.

To change an issue type, navigate to the Jira application settings and
select issues, then issue types.
Here we can see our new issue type with options to edit, delete, or
translate the issue type to a different language.
We will click on edit to change the icon for this issue type.

In the edit issue types screen, you can change the name, description, and
avatar, or icon, for the issue type.
We will click on select image to edit the avatar.

We can then select a new issue type avatar, or upload our own.

Now when we create a new issue in our project, we can select our new issue type.
You can see that it uses the icon that we selected.
Next, we will discuss using issue types in queries and swimlanes.

Basic search has a type drop-down that contains the issue types in your Jira
application.

You can see that this contains the default issue types, as well as any custom types.
We can see our new small issue type in the drop-down.

Here we have searched for all issues with the small issue type.
We can see that we have a single issue of this type.

If you click on the advanced search,
you will see that this issue type field is searched in the query.

A swimlane allows you to horizontally organize
issues with certain characteristics on a board.
For example, you could have a special row for expedited issues.
Here we have created a swimlane for our small issue type, so
that the small tasks are separated from normal issues on the board.

Swimlanes are configured using the swimlanes tab under board settings.

We have chosen to base our swimlane on queries, and
have added a swimlane named Small Tasks.
The JQL for this swimlane can select from any subset of the boards issues,
and this query selects for issues within issue type of small.

Any issues that are returned by this query are placed in a separate row on the board.
Every other issue that the boards filter matches will be shown
under the Everything Else heading.
We can drag and drop the order of the rows here if we would like to move
the Small Tasks row to the bottom of the board.

Here again is the board with the swimlane.
You can see that our query selected one issue for
the Small Task swimlane and the rest of the issues that match the boards
filter are shown under the Everything Else heading.


Each issue has an issue type field that identifies the type of work of the issue.

Each issue type can have unique fields, screens, and workflows.

Subtasks are issue types that must have a parent issue.

A collection of issue types used by projects is called an issue type scheme.

Jira allows you to customize issue types for each project.
Swimlanes can be configured on boards using any field, including issue type.

Now it's time for
you to work on some of the things that we've discussed in this video.
VIDEO 16
Configuring Issues
Reproducir video
reproducir
Volumen
0:00/11:37
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 configuring issues.

We will start by discussing labels.

Labels are a field used to help categorize and search for
issues in any way that makes sense to the team.
You can have multiple labels per issue.
This issue has two labels, refactor and database.

Labels can be added as you create an issue, or can be added to existing issues.
Jira will suggest existing labels as you type.

In this example, in the Create issue screen, we type an r and
we see that we can select the refactor label.
We could also type a new name and the label will be created.

You can click on a label in an issue and
Jira will take you to a search page containing all issues with this label.

Here's a search for issues with the label of refactor.

You can see that the field name is labels.
You can add this field to any search that you do in Jira.

Let's say that we are not interested in database related issues right now.

Here, we are searching for
issues with the label of refactor, but not a label with database.

Next, we will discuss configuring screens.

Screens display fields of an issue and can differ depending on the context.

Here's an example of a screen for creating issues for projectA.
If a field that your are interested in is not shown on the screen,
you can configure the screen to show it.
For example, the Story Points field is not shown on the screen.
Let's say that our team has decided that they would like that field shown
on the screen.
One limited option for
configuring the fields on a screen for the current user only
is to select from the Configure fields dropdown in the Create issue dialog.
All users see this dropdown.
All of the fields that are shown on this screen are listed with a checked box.

Notice that Story Points is not in the list.
We need to configure this as an administrator in a different location.

If you are a Jira administrator or the project administrator for this project,
you see the project settings icon in the contextual side bar.
If you view an issue in the issue navigator,
you will also see an admin dropdown.
Normal users do not see this dropdown.

This is one way that you can configure screens and add fields for
the current project.
To add a field to the screens,
navigate to an issue of the type that you would like to change, and click Add field.

In the Add Field dialog, enter the Story Points field, and then click Add field.

You'll then be able to add the Story Points value for this particular issue,
and you have configured the Story Points field to appear on other screens for
this project.

Now, when we click on Create issue for the project,
we can add a value to the Story Points field.

Here we are in the issue navigator for our projectA project.
We are viewing an issue, but there is no Story Points field shown.
This is because view screens will not show fields if a value has not been set.
We can click on the Edit link to change to the Edit issue screen.

In the Edit issue screen, we now see our Story Points field as expected.
Here, we specify a value of three Story Points and click Update to modify
the issue Now that we have assigned a value to the Story Points
field using the Edit issue screen, we can see the field in the View issue screen.

We used the Admin menu of the issue navigator to add the Story Points field to
screens.
For your information, here's a look at how to do the same thing in a different way.
It may help you better understand how Jira works, and
scope of the changes that you are making.

Here, we have clicked on the Fields tab in the contextual sidebar of the settings for
projectA.

Notice that Story Points is a field for the project, but
no screens have been configured to show it.
This is why the Story Points field wasn't showing on screens.

Here we have clicked on the Screens tab in the projectA settings sidebar.
This will show the Issue Type Screen Scheme used by this project.
An Issue Type Screen Scheme is a collection of screen schemes used for
specific issue types in the project.

This project uses two screen schemes.
The first screen scheme is used for issues of type Story, Epic, Task and Sub-task.
The second screen scheme is used for issues of type Bug.

The screen scheme for these four issue types contain three screens.
The Create issue, Edit issue, and View issue screens all use the same screen,
the Kanban Default Issue Screen for this project.
We can click on any of these screen names to configure it.

Here are the fields shown on the Kanban Default Issue Screens for our project.
You can see that Story Points is not a field on this screen.

At the bottom of the list of fields for this screen,
there's a dropdown where you can select a field to add it to the screen.

We can begin to type Story Points, then select the field to add it.

Now that we have modified the Kanban Default Issue Screen for this project,
the Story Points field will show in the Create issue and Edit issue screens.
And will show in the View issue screen if a value has been set for
the Story Points field.
Those were the things that happened automatically when you used the Admin menu
of the issue navigator to add a field to the screen.

Next, we will discuss custom fields.

Jira comes with a lot of default fields for a an issue.
In general, you want to try to keep things simple and
use those default fields whenever possible.
You can add custom fields to issues to answer specific needs of your team.
One way that administrators can add a custom field to issues of a project
is to view an issue with the issue navigator, select the Admin dropdown, and
click Add field.
This will add the field to your Jira application and
configure it to be used for this project.

We will create a field called Acceptance Criteria.
Acceptance Criteria are often used with stories.
For example, a product owner would write a list of criteria that must be true for
the story to be accepted as done.
We could add this list right in the description of the story, but
some teams may want to create a specific field for this.
Because Acceptance Criteria is not a name of a field in your Jira account,
you will be presented with the option to create the new field.
Click on that to enable the Create field button, and
continue creating the new field.

You are then presented with a Select a Field Type screen.
Each field has an associated type depending on what you want
to do with the field.
You can see that there are many standard types to choose from.
You can also click on the Advanced tab to view more types.
Since we want the product owner to create a free-form list of Acceptance Criteria,
we will select the multi-line Text Field as the field type.

You can then add a description for this field.
Here we have entered a description of a list of user-centered tests
that must pass for the story to be considered done.

You are then able to add the acceptance criteria for
the issue you originally selected.

Now, the new field will be shown when users work with issues in a project.
Here you can see the Acceptance Criteria field for an issue.

The Acceptance Criteria field is now visible on the Create issue screen,
along with our description of the field.

When we view an issue in the issue navigator,
if no Acceptance Criteria have been entered, we will not see the field.
This is because view screens do not show empty fields.
We can click on the Edit link to add Acceptance Criteria to this issue.

In the Edit issue screen, we see our Acceptance Criteria field,
and can enter a list of criteria.

If we navigate to our project settings and then to the Fields tab,
we can see that our previous configuration added the Acceptance Criteria field,
and added it to one screen.

If we click on that link,
we see that it is added to the Kanban Default Issue Screen for our project.
This is the screen used for Create, View, and Edit screens of the project.

If we view the Kanban Default Issue Screen for
our project, we see that Jira added the Acceptance Criteria field to the screen.

This is why it shows up on the Create, Edit and View screens.

If you navigate to Jira application level settings, Issues, and
then Custom fields, you will see that the Acceptance Criteria field is listed.
You can also see that it is associated with our project's Default Issue Screen.
You can click on the more icon to the right of the field to list more options
related to the field, such as changing the field name, setting a default value,
adding the field to more screens, or deleting the field.

You may have noticed that some field values are required.
For example, when you create an issue, the Project field is required.
This is because all issues must belong to one project.

For our custom Acceptance Criteria, we can set the field to be required by navigating
to the Jira application settings, then Issues, and then Field configurations.

In the default field configuration, we can see our Acceptance Criteria field,
along with a list of screens that contain the field.

You can see that the Default Issue Screen for
our project is the only screen that it will appear on.

Under Actions, we could make our field required by clicking the Required link.
There are also other available actions related to the field.
For example, we could add it more screens using the Screens link.


Labels are used to categorize and search for issues.
Screens display context-appropriate fields for an issue.

The Admin menu of the issue navigator can be used to create fields and
add fields to screens for a project.
Now, it's time for
you to work with some of the things that we've discussed in this video.

Modulo 3

Uploaded by

Copyright:

Available Formats

You might also like

Modulo 3

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulo 3

Uploaded by

Copyright:

Available Formats

VIDEO 12

This video discusses Quick Search and Basic Search.

Todas las notas

Play video starting at 10 seconds and follow transcript0:10

Play video starting at 14 seconds and follow transcript0:14

Play video starting at 22 seconds and follow transcript0:22

Play video starting at 41 seconds and follow transcript0:41

Play video starting at 54 seconds and follow transcript0:54

Play video starting at 1 minute 4 seconds and follow transcript1:04

Play video starting at 1 minute 9 seconds and follow transcript1:09

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

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

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

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

Play video starting at 2 minutes 5 seconds and follow transcript2:05

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

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

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

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

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

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

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

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

Play video starting at 4 minutes 5 seconds and follow transcript4:05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Play video starting at 7 minutes 1 second and follow transcript7:01

Play video starting at 7 minutes 8 seconds and follow transcript7:08

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

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

Play video starting at 8 minutes 1 second and follow transcript8:01

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

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

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

Play video starting at 9 minutes 5 seconds and follow transcript9:05

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

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

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

Play video starting at 10 minutes 11 seconds and follow transcript10:11

Play video starting at 10 minutes 27 seconds and follow transcript10:27

Play video starting at 10 minutes 34 seconds and follow transcript10:34

Play video starting at 10 minutes 44 seconds and follow transcript10:44

Play video starting at 10 minutes 50 seconds and follow transcript10:50

Play video starting at 10 minutes 58 seconds and follow transcript10:58