Skip to content
Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Jira ANalyze

jan the Jira ANalyze tool is a simple command line tool to extract information from JIRA which are not fetchable direct via JIRA in a structured way.

jan is a command based tool which means it comes with a central starting command (a.k.a jan) and subcommands from command line.

Installing jan


jan requires a Java 8 runtime environment at least.

Download jan

Download latest jan version from here.

Unzip the archive in a folder of your choice with

> unzip

where X is the version of jan


Add the jan directory to your PATH environment.

Using jan

Main parameters

jansupports 3 main parameters. The main parameters supports the connection of the subcommands against a remote JIRA instance.

h, --help
   Prints the help page.
   Default: false
-j, --jira
   JIRA connection URI.
-p, --password
   JIRA connection password.
-u, --user
   JIRA connection user.



Returns the count of the results of a JQL query. The result is printed to standard out.


    > jan --password secret --login jirauser --jira count \
          'project = MyProject and type = Bug and status = Closed'

The query prints a numeric value like 1234.


Analyze the fields returning by the given JQL query for field names and field types.

The return information is formatted in JSON and printed to standard out.


A general purpose command to get JQL query results from JIRA in a CSV format. The command support the current field values of the issues as well as the changelog history of fields.

Command line parameter

The issuequery support 4 command line parameters to configure the query and the result.


The parameter takes a list of fields and field pathes to get the current values. The parameter values are space delimited. In case of a field name with a space, the parameter value must be surrounded by quotation mark characters (U-0022).

In JIRA fields can be nested. This means a field can have additional fields. In such case the field must be described with a a field name path. The first part of the field name path is the root field. An undefined list of child path elements can follow. To distinguish between the path elements two colon (U+003a) characters are used as field path name delimiter.

For example:

To get the reporter of an issue the parameter value looks like the following:


To get the name of the creator of an issue the parameter looks like the following:


The parameter value referes to the issue field with name creator and the attribute name.

The reason for the is the field type. The reporter is a core field in a JIRA issue where the creator is not core field.

The fields key/issuekey and createdDate are implicit and must not been defined.

The parameter value is case insensitive.

Header name format

In case of a field name path the name of the header is the same as the field path name where the field path name delimiter is replaced with one underscore (U+005f) character.


The parameter takes a list of field names of the changelog to be exported. E.g. if the field name is


the result contains a list of from and to values of the summary. Additonal the output may contain the timestamp of the change and/or the duration from the previous change. See more at --temporal command line parameter.

The --history parameter doesn't support field name pathes.

The parameter value is case insensitive.


The parameter is only required if and only if --history field are defined. The parameter defines the temporal information in the output. It has 4 possible values.

Parameter valueDescriptionDefaultAbbreviation
noneNo temporal output is available for the changed field.non
timeThe timestamp of the change is part of the output.not
durationThe duration in milliseconds since the previous change is part of the output. For the first duration value the value of createdData of the issue is used.
Duration is a simplification for working with changelog information in dependend tools of the chain.
bothBoth temporal information (time and duration) are part of the output.nob

JQL query to get the data from JIRA.


The implementation currently writes the output as CSV format (RFC 4180) with header to stdout. The first column should contain the issue key. The second column should contain the createdDate value. It is recom

In case of changelog information in the output the names of the headers will have a prefix to the field name.

CSV changelog output prefix for example field name "issuetype"
Column typePrefixExample
From valuefrom_from_issuetype
Change date valueat_at_issuetype
Duration valueduration_duration_issuetype
To valueto_to_issuetype

Every changelog entry gets an own line in the CSV file. In case of more then one changelog field to export, every block gets its own lines but the blocks which are not the actual changelog field contains not values for the column.

The full set of current fields are available for every changelog line.

Datetime output

In case of datetime information the datetime format follows the human readable ISO 8601 format with milliseconds but no timezone information.

E.g. 2016-12-01T18:12:45.432


Fetch all relevant transition information for the tickets and print the values as CSV to standard out.

The only parameter for the command is the JQL query to fetch the data from remote JIRA.


    > jan --password secret --login jirauser --jira transition \
          'project = MyProject and type = Bug and (priority = Blocker or priority = Critical or priority = Major) ORDER BY key DESC'

Tip: Surround the query with apostrophe (U+0027) characters to avoid problems with the command line interpreter (I use bash on a Mac).


How can I work with https JIRA URIs

If running jan running against a JIRA instance protected with SSL, jan requires a trust store with the SSL certificate. jan requires this file in the user home directory - environment variable HOME - under ~/.jan/cacert

You can set a different trust store with the environment variable JAN_TRUST_STORE.

How can I setup a trust store

There are many dfferent types of how to configure your system with a trust store. I show you here how I did it in the past.

First there must be an installed openssl. That's the case on many Linux systems and Mac OS.

Get the SSL certificate with the following command line:

> openssl s_client -connect < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ~/public.crt

The domain name and port ( may differ on your system. Please contact your system administrator to get the correct data.

The result may look like the following:


You can trust now the cerificate or validate it. Nevertheless, the validation process is out of the scope of this FAQ.

Now create the ~/.jan/cacert trust store. First create the ~/.jan folder with

> cd
> mkdir .jan</br />

Now create the trust store with the following command line:

> keytool -v -import -file ~/public.crt -alias jira -keystore ~/.jan/cacert -storepass changeit

That's it. If all was done fine, the JIRA https connections with jan will work fine. In case of additional trouble please contact your system administrator.

NOTE: for reading from the trust store a password is not necessary.

Why is jan only for Unix like systems?

Because I've currently no Windows environment. But you are free to sponsor me a license :-)