A Guide to Creating JIRA Issues

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By Evanthika Amarasiri
  • 4 May, 2007


Atlassian JIRA is an open source issue tracking system we use in WSO2 projects to track all types of issues such as bugs, tasks, improvements, new features, etc.

While testing a particular product, if you come across an issue, you are free to report the issue in JIRA and assign it to a particular developer. When reporting an issue, you are expected to specify things like the build in which the issues were found, the priority of the issue, the build version that will be affected by the issue, the environment in which the issue was found, etc. This guide describes all these properties and makes life easy for the user who wants to create new JIRAs.

Creating a JIRA

Follow the steps given below to create a JIRA issue.

Step 1 - Logging In

On the JIRA home page, log on to the site to access the advanced functions such as creating and editing issues.

Step 2 - Accessing the 'Create New Issue' Link

After logging on, click the link CREATE NEW ISSUE. The page Step 1 of 2 will be displayed. Select the project along with the issue type.

Step 3 - Specifying the Issue Properties

Step 2 of 2 loads the page on which you can set the rest of the options. At this point, the project and the issue type selected in Step 1 of 2 will be loaded automatically.

You can also select the project on the home page itself. Then when you click the link CREATE NEW ISSUE, the first page (Step 1 of 1) will be loaded with the selected project, so that you will not have to select the project again.

The following properties of a JIRA issue need to be specified when creating a JIRA bug/task/new feature.

  1. Project
  2. Issue Type
  3. Summary
  4. Priority
  5. Component/s
  6. Affects Version/s
  7. Fix Version/s
  8. Environment
  9. Description

We will see what each of the above means and how you should set these properties when creating a JIRA.

Project: The name of the project in which the issue was found. You can either select the project from the home page or from the page “Step 1 of 2: Choose the project and issue type”. Depending on the project you selected, the components will be loaded on the Step 2 of 2 page. For example, the values given in the Components, Affects Version/s, and Fix Version/s fields will depend on the project that you select, e. g., WSO2 WSAS-Java.

Issue Type: The type of the issue differs according to the nature of the issue. An issue can be a bug, a new feature, an improvement, or a task. In addition to this, an administrator can define any number of custom types such as Test, Wish, etc. The issue types can be any of the following.

    a) Bug - A fault of the system, which prevents it from working as intended or produces an incorrect result.
    Example: WSDL2Java generates an invalid Addressing action header

    b) New Feature - There may be some new functions which are expected to be added to the project. They can be reported as New Features in JIRA, and assigned to someone so that it can be easily followed up.
    Example: Provide a pluggable mechanism to handle servicepath foo handling

    c) Improvement - This can be either an enhancement of an existing feature or an improvement that needs to be done in a document.
    Example: Providing the 'Restore defaults' option in Logging Management

    d) Task - A task that has to be done can be reported as a Task, and assigned to somebody, so that he or she will not loose track of it.
    Example: Remove the minimal distribution from releases.

Summary: A very short description of what the issue is about. You should try to make the summary very simple and clear, so that the overview of the issue can be understood through this. Example: Class loading error occurred in the Eclipse Codegen wizard when AXIOM references are available in the service class.

Priority: The priority of an issue is how important the issue is in relation to the other issues that have been reported. Usually the developers attend to the issues based on priority. For example, if the priority of an issue is "Blocker" then that is considered as a high priority issue and should be attended to immediately. An issue can be prioritized as Blocker, Critical, Major, Minor, or Trivial.

    a) Blocker - Blocker type issues are the most critical issues. You will not be able to use the product if this type of issue occurs.
    Example: Unable to log on to the system.

    b) Critical - This type of issue is critical to the system and you need to attend to these issues as soon as possible.
    Example: An exception occurring when performing a particular function, (i.e., adding a user to the system)

    c) Major - Issues that are important and should be fixed but does not stop the rest of the system from functioning.
    Example: When adding one record, the same record gets added twice.

    d) Minor - These issues have a relatively minor impact on the product but needs to be fixed.
    Example: Wrong message being displayed when some action is performed.

    e) Trivial - Trivial issues have the least impact on the product.
    Example: Spelling error in an error message, GUI Issues, etc.

Component/s: The component in which the issue was found. For example, if the issue was found while testing the samples, you can select “samples” as the component. If you do not know in which component the issue was raised, you can either select Unknown or leave the field empty. These components are identified by the developers and are added to the JIRA before the product is sent for testing. Some examples of the components in the WSO2 WSAS for Java C project are – admin, core, documentation, integration, MgtConsole-UI, samples, servlet-edition, etc.

Affects Version/s: This represents the version in which the issue is found. Before giving a build for testing, the administrator makes sure to add the build names to this list. Assume that the build 1.0-RC1-B1 was given for testing. Therefore, when reporting issues on this build, you can select the Affected Version as 1.0-RC1-B1. This is useful for the developers to figure out in which build they have to fix the issue. Selecting this option is very helpful for future releases because if the same type of issue occurs in the future, developers can easily compare the builds and fix the issue.

Fix Version/s: Once a bug has been resolved by a developer, it is being sent to the person who tested it for verification. This option is very important for the user to know the build in which the issue was resolved. Then the developer will know in which build to verify the issue.

Environment: The environment in which the issue occurred. This can include the operating system, software platforms, hardware specifications, etc. For example, Windows XP, Windows XP, JDK 1.4.2_13, Firefox version, Jakarta-tomcat-4.1.30

Description : A step-by-step description of how to re-create the issue. The description should be given in such a manner that anyone can follow the steps and reproduce the issue without any hassle. If the issue is on an exception that was thrown, add the exception at the end of the description so that the developers can figure out what the issue is without having to carry out the steps to re-create the error.

For example,

  1. Go to Logging
  2. Select Configure Log4J Appenders as WSO2WSAS_LOGFILE
  3. Specify a path which does not exist in the file system.
  4. Click Update.
  5. An error message is given as "null". Got the following exception on the console.
  6. ERROR [2006-11-30 14:38:11,593] Exception occurred while trying to invoke service method update
    AllAppenderData java.lang.reflect.InvocationTargetException
    at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver.invokeBusinessLogic (RPCInOnlyMessageReceiver.java:85)
    at org.apache.axis2.receivers.AbstractInMessageReceiver.receive (AbstractInMessageReceiver.java:35)
    at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493)

Step 4 - Submitting the Issue

Once you have filled all the fields, click Create. A new JIRA issue will be created with a new issue number.

Well done!!! You have successfully created your very own JIRA.


Users who dig into the products of WSO2 can report any issues which they find. For this purpose, they can use the JIRA issue tracking tool to report issues such as bugs, improvements, new features, etc. This guide teaches the users to create a JIRA issue without a hassle.


1. JIRA, the Professional Issue Tracker

2. What is an issue?



Evanthika Amarasiri, Software Quality Assurance Engineer, WSO2 Lanka (Pvt) Limited, evanthika at wso2 dot com

    About Author

    • Evanthika Amarasiri
    • Senior Technical Lead
    • WSO2