In this page

Integration with other Jira apps
Automation Lite for Jira
Integration features
Configuration
Learn more about Automation Lite for Jira
Insight
Integration features
Export samples
Configuration
Exporting Insight custom fields
Configuring the export format for Insight custom fields
Configuring the Excel report template for Insight
Learn more about Insight
Jira Service Desk
Integration features
Export samples
Configuration
Exporting Jira Service Desk custom fields
Configuring the Excel report template for Jira Service Desk
Learn more about Jira Service Desk
Jira Software
Integration features
Export samples
Configuration
Exporting Jira Software custom fields
Configuring the Excel report template for Jira Software
Learn more about Jira Software
nFeed
Integration features
Export samples
Configuration
Exporting nFeed custom fields
Configuring the export format for nFeed custom fields
Configuring nFeed displays for Excel exports
nFeed troubleshooting
When I uninstall or disable the nFeed app, it also disables the Better Excel Exporter app
There is a "Failed to find the nFeed API" warning in my Jira log
Learn more about nFeed
ScriptRunner
Integration features
Configuration
Learn more about ScriptRunner
Tempo Timesheets
Integration features
Export samples
Configuration
Exporting Tempo custom fields
Enabling the Tempo servlet
Configuring the Excel views for Tempo
Configuring the Excel templates for Tempo
Configuring the period filter for Tempo worklogs
Configuring the user filter for Tempo worklogs
Configuring pre-loading for Tempo worklogs
Configuring the Tempo servlet request details
Learn more about Tempo Timesheets
Time to SLA
Integration features
Export samples
Configuration
Exporting Time to SLA custom fields
Configuring the export format for Time to SLA custom fields
Learn more about Time to SLA
Zephyr
Integration features
Export samples
Configuration
Installing ZAPI
Configuring the REST API for Zephyr
Why do all REST API calls result in "Server returned HTTP response code: 403" or "401" error?
Zephyr troubleshooting
Only the first 1000 Zephyr tests and executions are exported
Zephyr exports only work for the issue type called "Test"
"Executed On" does not include the time part (only the date)
When exporting step results, "Step", "Test Data", "Expected Result" and "Comment" texts are joined to a single-line string
When exporting step results, step defects are not associated with the steps, but with the executions
I am using some older Zephyr version and the export does not work
Learn more about Zephyr

Integration with other Jira apps

This page describes how Better Excel Exporter for Jira exports data from, or integrate with popular Jira apps.

If an app is not mentioned here, it does not mean that it would not work in Excel reports. This page only lists the most important apps, that are actively used by the Better Excel Exporter user community and whose integration is officially supported by Midori.

Automation Lite for Jira

Automation Lite for Jira is a flexible automation app for Jira (similar to the IFTTT or Zapier services). (supported since Better Excel Exporter 1.0.0)

This allows to create automation rules from triggers (when should happen?) and actions (what should happen?):

Integration features

  • Better Excel Exporter extends Automation Lite with Send Excel in email, Save Excel to the file system and Attach Excel to an issue actions to email, export and attach Excel reports from Jira at regular intervals (periodic job) or at issue events (issue created, updated, assigned, etc.)

Configuration

Read the automation tutorial for a complete how-to.

Learn more about Automation Lite for Jira

See the Automation Lite for Jira page (at its own vendor).

Insight

Insight is the leading asset management app for Jira, that allows implementing CMDB, CRM, HR, ITSM or ITIL functionality on the Jira platform. (supported since Better Excel Exporter 2.5.0)

Watch this short introductory video to see how fast you can export your Insight data to Excel:

Integration features

  • You can export all Insight-specific custom field types like Insight Object (single select), Insight Object (multi select), Insight Referenced Object (single select), Insight Referenced Object (multi select) and Insight Object (read only) to Excel.
  • You can configure the export format to include object names (e.g. "My supa dupa server"), object keys (e.g. "My supa dupa server [SRVR-123]"), object attributes (e.g. "My supa dupa server [SRVR-123] (Manufacturer=Cray Research, Vector Processors=4, Type=Supercomputer)") and any combination of these.
  • Better Excel Exporter also offers a reporting template that includes several pivot table and pivot chart worksheets to calculate issue count, project distribution and status distribution by Insight object. Although this is useful as is, this can also be used as a starting point to create custom Excel reports from Insight data.

Export samples

See the Template Gallery for sample files exported from Insight.

Configuration

Exporting Insight custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the Insight managed fields and export them accordingly.

Configuring the export format for Insight custom fields

The default behaviour is that object names and object keys will be exported (e.g. "My supa dupa server [SRVR-123]"). You can include object name, object key and attributes by setting these configuration variables in the top part of the field-helper-tool.groovy script:

// field-helper-tool.groovy

/* Insight configuration. */
def insightObjectsWithNames = true
def insightObjectsWithKeys = true
def insightObjectsWithAttributes = false

If you want full control over the export format, please see this easy-to-read method in field-helper-tool.groovy:

private def insightObjectToString(def object)
Configuring the Excel report template for Insight

The template insight-report.xlsx contains a placeholder for the Insight managed custom field, which should be correctly configured before generating reports.

Steps:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsExcel Views.
  3. Click the view Insight (Excel), change its context to at least the "Issue Navigator" and submit. (This view was not enabled by default.)
  4. Go to AdministrationAdd-onsExcel Templates.
  5. Download the template insight-report.xlsx.
  6. Open the file in Microsoft Excel for editing.
  7. Go to the last worksheet, check the first cell in the second row that contain an expression like <jt:forEach items="${issues}" var="issue"><jt:forEach items="${insight.getObjects(issue, 'customfield_10123')}" var="object">${issue.key}. Replace the placeholder custom field ID customfield_10123 with the actual ID of that custom field (see this section for help). For instance, if the ID is 10456 in your Jira instance, then change the expression to <jt:forEach items="${issues}" var="issue"><jt:forEach items="${insight.getObjects(issue, 'customfield_10456')}" var="object">${issue.key}.
  8. Save the Excel file (do not change its name!) and upload that to Jira.
  9. For testing, go to Issue Navigator. Export an Excel file with the Insight (Excel) view, and check whether the cell values are correctly exported in the last worksheet.
    If those are, you are done.
    If not, check the custom field IDs again in the template.

(Please note that this is easy, and you have to configure this only once.)

Learn more about Insight

See the Insight page (at its own vendor).

Jira Service Desk

Jira Service Desk is the de-facto service desk solution running on the top of Jira. (supported since Better Excel Exporter 1.1.0)

Give this short video a watch to see how to export tickets and create reports directly from Service Desk queues in Excel:

Integration features

  • You can export Excel reports directly from the Queue view (with all tickets in the queue). (supported since Better Excel Exporter 2.2.0)
  • You can export the Jira Service Desk-specific custom field types, like Customer Request Type, Organizations, Request Participants, Satisfaction, SLA to Excel.
  • Better Excel Exporter also offers a reporting template that includes several pivot table and pivot chart worksheets to report SLA by projects, assignees, request types and request participants.

Export samples

See the Template Gallery for sample files exported from Jira Service Desk.

Configuration

Exporting Jira Service Desk custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the Jira Service Desk managed fields and export them accordingly.

Configuring the Excel report template for Jira Service Desk

The template jira-service-desk-report.xlsx contains placeholders for Jira Service Desk managed custom fields, which should be correctly configured before generating reports.

Steps:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsExcel Views.
  3. Click the view Jira Service Desk (Excel), change its context to at least the "Issue Navigator" and submit. (This view was not enabled by default.)
  4. Go to AdministrationAdd-onsExcel Templates.
  5. Download the template jira-service-desk-report.xlsx.
  6. Open the file in Microsoft Excel for editing.
  7. Go to the last worksheet, check the cells in the second row that contain an expression like ${fieldHelper.getFieldValue(issue, "customfield_10123")}. Replace the placeholder custom field ID customfield_10123 with the actual ID of that custom field (see this section for help). For instance, if the ID is 10456 in your Jira instance, then change the expression to ${fieldHelper.getFieldValue(issue, "customfield_10456")}.
  8. Repeat this for the following columns: Customer Request Type, Request Participants and Time to Resolution.
  9. Save the Excel file (do not change its name!) and upload that to Jira.
  10. For testing, go to Issue Navigator. Export an Excel file with the Jira Service Desk (Excel) view, and check whether the cell values are correctly exported in the last worksheet.
    If those are, you are done.
    If not, check the custom field IDs again in the template.

(Please note that this is easy, and you have to configure this only once.)

Learn more about Jira Service Desk

See the Jira Service Desk page (at its own vendor).

Jira Software

Jira Software is the Scrum and Kanban solution for Jira. (supported since Better Excel Exporter 1.1.0)

Watch how easy it is to export issues from the backlog to Excel or create in-depth pivot reports from Jira Software data:

Integration features

  • You can export Excel reports directly from the Backlog (with all issues in a sprint or in the backlog), Scrum Board and Kanban Board views (with all issues in a column). (supported since Better Excel Exporter 2.2.0)
  • You can export the Jira Software-specific custom field types, like Sprint, Epic, Story Points, Development (including branch, commit and pull request information), etc., to Excel.
  • Better Excel Exporter also offers a reporting template that includes several pivot table and pivot chart worksheets to report story points by projects, assignees, sprints and epics.

Export samples

See the Template Gallery for sample files exported from Jira Software.

Configuration

Exporting Jira Software custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the Jira Software managed fields and export them accordingly.

Configuring the Excel report template for Jira Software

The template jira-agile-report.xlsx contains placeholders for Jira Software managed custom fields, which should be correctly configured before generating reports.

Steps:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsExcel Views.
  3. Click the view Jira Software (Excel), change its context to at least the "Issue Navigator" and submit. (This view was not enabled by default.)
  4. Go to AdministrationAdd-onsExcel Templates.
  5. Download the template jira-agile-report.xlsx.
  6. Open the file in Microsoft Excel for editing.
  7. Go to the last worksheet, check the cells in the second row that contain an expression like ${fieldHelper.getFieldValue(issue, "customfield_10123")}. Replace the placeholder custom field ID customfield_10123 with the actual ID of that custom field (see this section for help). For instance, if the ID is 10456 in your Jira instance, then change the expression to ${fieldHelper.getFieldValue(issue, "customfield_10456")}.
  8. Repeat this for the following columns: Epic (Link), Sprint, Business Value, Story Points and Flagged.
  9. Save the Excel file (do not change its name!) and upload that to Jira.
  10. For testing, go to Issue Navigator. Export an Excel file with the Jira Software (Excel) view, and check whether the cell values are correctly exported in the last worksheet.
    If those are, you are done.
    If not, check the custom field IDs again in the template.

(Please note that this is easy, and you have to configure this only once.)

Learn more about Jira Software

See the Jira Software page (at its own vendor).

nFeed

The nFeed app integrates external data sources (SQL databases, LDAP, Active Directory, REST APIs, Salesforce, CSV files, etc.) to Jira. (supported since Better Excel Exporter 2.6.0)

Watch this short introductory video to see how fast you can export your nFeed data to Excel:

Integration features

  • You can export the nFeed-specific custom field types like nFeed, nFeed - Date, nFeed - DateTime, nFeed - User (and even the legacy nFeed [deprecated]) to Excel.
  • Better Excel Exporter supports custom reporting on nFeed custom fields, using pivot tables, pivot charts and all other Excel features.
  • Note that although Better Excel Exporter 2.6.0 supports Jira 6.2 or newer, this particular integration works only with Jira 6.4 or newer (due to nFeed).

Export samples

See the Template Gallery for sample files exported from nFeed.

Configuration

Exporting nFeed custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the nFeed managed fields and export them accordingly.

Configuring the export format for nFeed custom fields

nFeed standard fields have customizable "display templates" that show the field values in the web interface. Display templates can contain arbitrary HTML code, but HTML formatting cannot always be represented in Excel. For instance, although multi-value nFeed fields are frequently displayed as HTML lists or HTML tables in the web interface, a table cannot be intuitively "fit" into an Excel cell.

Therefore, a transformation converts the value in the web interface to the value in the Excel cell. The default implementation transforms nFeed fields to comma-separated lists, regardless their original HTML representation. It simply removes the HTML tags from the HTML representation and concatenates the body texts using comma as separator.

For example, an HTML list:

<ul>
	<li>value1</li>
	<li>value2</li>
	<li>value3</li>
</ul>

will be exported to:

value1, value2, value3

Or an HTML table:

<table>
	<tr>
		<td>value11</td>
		<td>value12</td>
		<td>value13</td>
	</tr>
	<tr>
		<td>value21</td>
		<td>value22</td>
		<td>value23</td>
	</tr>
</table>

will be exported to:

value11, value12, value13, value21, value22, value23

This approach works intuitively in most situations, but if you want full control over the logic, please see the one-line transformer method xmlToDelimitedString() in field-helper-tool.groovy. This accepts the nFeed HTML value in the xml argument and the comma character in delimiter, then returns the string value to be inserted to the Excel cell. You can redefine the logic by modifying this method:

/**
 * Returns the body text fragments from the passed XML joined with the delimiter.
 * The XML is not required to be well-formatted and can even be plain text.
 */
private def xmlToDelimitedString(def xml, def delimiter) {
	xml.split(/<.*?>/).collect{ it.trim() }.findAll{ !it.allWhitespace }.join(delimiter)
}

If the transformation is OK, but you want to change the delimiter passed to xmlToDelimitedString, change that at the method invocation in field-helper.groovy:

// nFeed custom field types
case "com.valiantys.jira.plugins.SQLFeed:nfeed-standard-customfield-type":
case "com.valiantys.jira.plugins.SQLFeed:com.valiantys.jira.plugins.sqlfeed.user.customfield.type":
case "com.valiantys.jira.plugins.SQLFeed:com.valiantys.jira.plugins.sqlfeed.customfield.type":
	// it is invoked below!
	(value != null) ? xmlToDelimitedString(nFeedDisplayToString(issue, customField), ", ") : null
	break

For instance, to change from comma to line-break, modify the corresponding line to (note that last argument changed!):

(value != null) ? xmlToDelimitedString(nFeedDisplayToString(issue, customField), "\n") : null
Configuring nFeed displays for Excel exports

As written above, the transformation from nFeed to Excel relies on on the body text fragments separated by HTML tags. Therefore, you can fully control where to insert the commas (or other delimiters) in Excel by adding or removing HTML tags to the display template of the nFeed field. Depending on what tags you add, you can also control if those are shown with or without line breaks in the web interface.

This is best explained with some trivial display templates, all using multiple items with two variables {0} (key) and {1} (value):

<!--
	web interface: no line-breaks
	Excel: "key1 - value1, key2 - value2, key3 - value3"
-->
<span>{0} - {1}</span>

<!--
	web interface: no line-breaks
	Excel: "key1, value1, key2, value2, key3, value3"
-->
<span>{0}</span><span>{1}</span>

<!--
	web interface: with line-breaks
	Excel: "key1 - value1, key2 - value2, key3 - value3"
-->
<div>{0} - {1}</div>

<!--
	web interface: with line-breaks
	Excel: "key1, value1, key2, value2, key3, value3"
-->
<div>{0}</div><div>{1}</div>

<!--
	web interface: list items (an <ul> or <ol> element is expected to wrap these, of course)
	Excel: "key1 - value1, key2 - value2, key3 - value3"
-->
<li>{0} - {1}</li>

<!--
	web interface: table cells (a <table> is expected to wrap these, of course)
	Excel: "key1, value1, key2, value2, key3, value3"
-->
<tr><td>{0}</td><td>{1}</td></tr>

nFeed troubleshooting

When I uninstall or disable the nFeed app, it also disables the Better Excel Exporter app

This is a very infrequent and random problem, which is deeply rooted in Jira's OSGi component dependency management. Solution: simply re-enable Better Excel Exporter (via the Universal Plugin Manager) and it will work.

There is a "Failed to find the nFeed API" warning in my Jira log

Just like previous one, this is rare and random, also related to OSGi and Jira's internal ComponentAccessor returning a null object as nFeed API. Solution: simply reinstall Better Excel Exporter and it will work (and it will not happen again). (Note: even with the warning written to the log, the export falls back to a simplified mode and gives a so-so result for the users.)

Learn more about nFeed

See the nFeed page (at its own vendor).

ScriptRunner

ScriptRunner is the most powerful tool to implement every kind of custom logic, expressed as Groovy scripts, in Jira. (supported since Better Excel Exporter 1.1.0)

Watch this video to see how to run custom scripts (by ScriptRunner) to create and email periodic Excel reports (by Better Excel Exporter):

Integration features

  • The Excel API provided by the Better Excel Exporter app fully supports ScriptRunner. Midori actually recommends Groovy as the generally best choice of language to implement automations and integrations that rely on the Excel API.

Configuration

Read the Excel API tutorial for a complete how-to.

Learn more about ScriptRunner

See the ScriptRunner page (at its own vendor).

Tempo Timesheets

Tempo Timesheets is the most widely used time tracking solution for Jira. (supported since Better Excel Exporter 1.1.0)

Watch this short video to see how to create custom worklog reports from Tempo Timesheets data:

Integration features

  • You can export Excel reports directly from the Timesheet (with all issues in the timesheet), Calendar (with all issues in the selected period), Report (with all issues in the report) and List views (with all unique issues in the list). (supported since Better Excel Exporter 2.2.0)
  • You can export the Tempo-specific custom field types, like Account, Team, Iteration, etc., to Excel.
  • You can export the Tempo managed worklogs to Excel along with their custom worklog attributes. You can optionally filter the Tempo worklogs by start date and end date or to exclude the non-billable worklogs, for example.
  • Better Excel Exporter also offers a reporting template that includes several pivot table and pivot chart worksheets to report planned and spent time by projects, assignees, accounts, iterations and teams.

Export samples

See the Template Gallery for sample files exported from Tempo Timesheets.

Configuration

Exporting Tempo custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the Tempo managed fields and export them accordingly.

Enabling the Tempo servlet

If you wanted to export Tempo worklogs, Excel templates download those from the Tempo servlet during the spreadsheet rendering. Tempo servlet is basically Tempo's HTTP based API.

Please execute the following steps to allow the templates accessing the servlet:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsAccess Control (under Tempo).
  3. Enter "127.0.0.1" (localhost) or the Jira server's actual IP to "Allowed addresses", and "Save" the changes.
  4. Copy the "Security token" string to the clipboard.
  5. Go to AdministrationAdd-onsExcel Templates (under Excel Views).
  6. Download the file tempo-tool.groovy.
  7. Open the file in any plain text editor for editing.
  8. Paste the security token from the clipboard to the value in the top part:
    // tempo-tool.groovy
    
    tempoApiToken = '3022ac1e-db73-4c54-9c15-cceccbb94554'
    
  9. Save the Groovy file (do not change its name!), and upload that to Jira.
  10. For testing, go to Issue Navigator. Export an Excel file with the Tempo Worklogs (Current f.) view, and check whether the cell values are correctly exported in the last worksheet.
    If those are, you are done.
    If you are seeing java.io.IOException: Server returned HTTP response code: 401 for URL or similar error messages in the cells, check the Tempo API token again in tempo-tool.groovy.

(Please note that this is easy, and you have to configure this only once.)

After you set up the Tempo servlet access, you may want to configure the details of exporting the worklogs. There are several straightforward configuration parameters in the top part of the tempo-tool.groovy script.

Configuring the Excel views for Tempo

By default, Tempo related Excel views are disabled.

Steps to enable them:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsExcel Views.
  3. Edit the view Tempo Worklogs (All fields), set the type to "All", and submit.
  4. Edit the view Tempo Worklogs (Current f.), set the type to "Tempo Timesheet" (or "Multiple Issues" in pre-2.2.0 versions), and submit.
  5. Edit the view Tempo (Excel), set the type to "Tempo Timesheet" (or "Multiple Issues" in pre-2.2.0 versions), and submit.

Then the Excel options become available in the Export drop-downs:

Configuring the Excel templates for Tempo

The template tempo-report.xlsx contains placeholders for the Tempo managed custom fields, which should be correctly configured before generating reports.

Steps:

  1. Login to Jira as administrator.
  2. Go to AdministrationAdd-onsExcel Views.
  3. Click the view Tempo Worklogs (All fields), change its context to at least the "Issue Navigator" and submit. (This view was not enabled by default.)
  4. Go to AdministrationAdd-onsExcel Templates.
  5. Download the template tempo-report.xlsx.
  6. Open the file in Microsoft Excel for editing.
  7. Go to the last worksheet, check the cells in the second row that contain an expression like ${fieldHelper.getFieldValue(issue, "customfield_10123")}. Replace the placeholder custom field ID customfield_10123 with the actual ID of that custom field (see this section for help). For instance, if the ID is 10456 in your Jira instance, then change the expression to ${fieldHelper.getFieldValue(issue, "customfield_10456")}.
  8. Repeat this for the following columns: Account, Iteration and Team.
  9. Save the Excel file (do not change its name!) and upload that to Jira.
  10. For testing, go to Issue Navigator. Export an Excel file with the Tempo Worklogs (All fields) view, and check whether the cell values are correctly exported in the last worksheet.
    If those are, you are done.
    If not, check the custom field IDs again in the template.

(Please note that this is easy, and you have to configure this only once.)

Configuring the period filter for Tempo worklogs

If there is a time period specified, then the tempo-tool.groovy script exports only the worklogs in that time period. The time period is specified by a start- and an end date passed in request parameters.

Start and end date are available in Tempo contexts (like the Timesheet screen), but not available in others (like the Issue Navigator screen). This is simply because while the Tempo contexts offer a period selector, Issue Navigator doesn't.

For this latter case, the period is basically "all times". You can configure the default period by setting the values in the end of these expressions:

// tempo-tool.groovy

def tempoDateFrom = tempoDateFromRequestParameter ?: '2000-01-01'
def tempoDateTo = tempoDateToRequestParameter ?: '2099-12-31'

Or, you can disable the filter by ignoring the period passed and forcing "all times":

// tempo-tool.groovy

def tempoDateFrom = '2000-01-01'
def tempoDateTo = '2099-12-31'
Configuring the user filter for Tempo worklogs

Since app version 3.4.0, the tempo-tool.groovy script can export the worklogs of only one specific user if the username is passed in a request parameter.

The username is available in Tempo contexts (like in the Timesheet screen), but not available in others. Again, this is simply because the user selector is available only in Tempo contexts.

You may want to disable this filtering also in Tempo contexts, in order to export the worklogs for all users. The most typical use case example is creating a monthly report that accumulates the work of every team member. To disable the filtering, set this configuration variable to true:

// tempo-tool.groovy

def exportWorklogsOfAllUsers = false
Configuring pre-loading for Tempo worklogs

Since app version 3.4.0, tempo-tool.groovy script supports two loading strategies: "pre-load worklogs for all issues" vs. "load worklogs for each issue separately".

In our profiling, the former works faster for larger number of issues, i.e. when we expect a larger number of worklogs to be returned. These requests can be served faster if all the worklogs in the period are downloaded with a single Tempo API call (instead of one Tempo API call per issue).

There is a potential danger to consider! If you have a large number of issues and the period is "all times" (or very long), then pre-loading can generate heavy load on Tempo. Therefore, by default pre-loading is used only if there are more than 10 issues to export and the period is not "all times" (but some specific start and end date)!

This is the expression in tempo-tool.groovy that captures the default decision logic, allowing to change the value of 10 issues:

preloadWorklogs = (issues.size() > 10) && !exportWorklogsOfAllTimes

If you are not worried about longer periods and want to make it depend only on the issue count, you can reduce the decision to this:

preloadWorklogs = (issues.size() > 10)

Or, you can enforce pre-loading (in every case) by deleting the right-side expression and setting the variable to true:

preloadWorklogs = true
Configuring the Tempo servlet request details

If you wanted to change the low-level details of invoking the Tempo servlet, you can do that by editing the tempo-tool.groovy script. The script itself is short and very easy to understand. You can change the servlet's URL by editing this line, for instance:

def url = "${baseUrl}/plugins/servlet/tempo-getWorklog/?dateFrom=${dateFrom}&dateTo=${dateTo}&format=xml&addBillingInfo=true&addUserDetails=true&tempoApiToken=${apiToken}"

Learn more about Tempo Timesheets

See the Tempo Timesheets page (at its own vendor).

Time to SLA

Time to SLA is a popular choice to implement Service Level Agreements (SLAs) on Jira issues. It helps to set up, track and measure SLAs based on issue events (status change, resolution, reopen, etc.). (supported since Better Excel Exporter 3.4.0)

Integration features

  • You can export the Time to SLA specific custom field types like Time to SLA, Overdue Status, SLA Indicator, SLA Overview, TTS - Time String and TTS - SLA Dates to Excel.

Export samples

See the Template Gallery for sample files exported from Time to SLA.

Configuration

Exporting Time to SLA custom fields

There is nothing to do. Better Excel Exporter will automatically recognize the Time to SLA managed fields and export them accordingly.

Configuring the export format for Time to SLA custom fields

While some Time to SLA custom fields display simple values (like a single date), some others display fairly complex ones (like a complete SLA history). Complex values are exported to Excel cells using the structured left-indented text format that we found the most intuitive:

[Time in "To Do"]
	Issue met SLA
	1 hours, 50 minutes, 29 seconds
[Time in "In Progress"]
	Issue met SLA
	11 hour, 34 minutes, 7 seconds
[Time in "Waiting for customer"]
	SLA is running
	1 hour, 56 minutes, 18 seconds

You can freely customize the output format by modifying these methods in the field-helper-tool.groovy script:

// field-helper-tool.groovy

private def overdueStatusToString(def ttsFieldValue)
private def slaIndicatorToString(def ttsFieldValue)
private def slaOverviewToString(def ttsFieldValue)
private def timeToSlaToString(def ttsFieldValue)

Not only you can use and modify the information you can see in the original implementation of these methods, you can also access additional information. Those are specific to the custom field type.

For example, to display the time in milliseconds for the Time to SLA custom field values, change the it.timeToSlaAsString expression to it.timeToSla in the timeToSlaToString() method. For a comprehensive guide, please refer to the official Time to SLA developer documentation

Learn more about Time to SLA

See the Time to SLA page (at its own vendor).

Zephyr

Zephyr is the most popular test management solution for the Jira platform. (supported since Better Excel Exporter 3.2.0)

Watch this short video to get the gist of exporting Zephyr tests to Excel reports:

Integration features

  • You can export the test steps for any test list. As Zephyr tests are regular Jira issues, this enables creating Excel files from fields (test details) plus test steps (instructions) with a single click.
  • You can export the test executions for any test list. Executions are exported with their details for a comprehensive report: ID, test cycle, version, execution status, assignee, executor user, execution date, execution defects, step defects and comments.
  • You can export the test step results of the test executions for detailed test reports. The following details are exported for each step: ID, step instructions, test data, expected result, execution status, and comments.
  • Better Excel Exporter also offers a reporting template that includes several pivot table and pivot chart worksheets to calculate test results by projects, test cycles, versions, testers or find defects by test cycles or individual tests. Although this is useful as is, this can also be used as a starting point to create custom Excel reports from Zephyr data.

Export samples

See the Template Gallery for sample files exported from Zephyr.

Configuration

Installing ZAPI

Please note that the Zephyr app itself does not expose any public API. Instead, there exists a separate app called ZAPI (developer by the Zephyr team), to provide a REST API for Zephyr tests, test executions and so.

The Zephyr + Better Excel Exporter integration relies on the REST API provided by ZAPI. Therefore, please install ZAPI with a valid license as the starting step. (Note: ZAPI is a paid app. For evaluation purposes, a free trial license will work, too.)

Configuring the REST API for Zephyr

As this integration relies on the Zephyr REST API, you need to configure the login credentials of a valid Jira user account for the REST API calls. Please set the username and password to these configuration variables in zephyr-tool.groovy:

/* Zephyr REST API request parameters. */
def restUserName = "admin"
def restPassword = "admin"

Don't worry about using plain text passwords: this file is visible only for Jira administrators, who would have super-user permissions any way.

As a good practice, this is safer to avoid usernames and passwords that contain non-English characters. Albeit our Zephyr script correctly encodes international usernames and passwords, their handling also depends on the configuration of the container that hosts your Jira web application (typically Tomcat). If you're having difficulties, just replace those characters in your username or password with English letters or numbers.

Why do all REST API calls result in "Server returned HTTP response code: 403" or "401" error?

First off, be 101% sure that the REST username and password are correct. If those are, but you are still receiving 403's, please open Jira in your browser, logout and login with the same user account which you configured for the REST calls. You will be asked for a CAPTCHA verification, but after answering that and logging in to Jira, the REST calls will also be successfully executed!

Why does this happen? As its default behavior, Jira will lock your account and present a CAPTCHA on the login form after a few (3 - 5) unsuccessful login attempts. Since the Zephyr integration may send several REST API requests per export, the unsuccessful login attempts limit can be reached very quickly if the password is wrong. To resolve this: you just have to pass the CAPTHCA verification, that's it.

Please note that it will never happen again, unless you change the password of the corresponding Jira user account.

If you are an administrator, there is also a quicker solution: go to Administration → User management and clear the failed login attempts counter with one click.

Tip: you can increase the allowed login attempts or even disable this feature altogether in Jira.

Zephyr troubleshooting

Only the first 1000 Zephyr tests and executions are exported

This is a limit exposed by the Zephyr API for performance reasons. (Their documentation does not mention about lifting this limit, so you are encouraged to contact their support team.)

Zephyr exports only work for the issue type called "Test"

In order to minimize the Zephyr API calls, the zephyr-tool.groovy script does not send an API request to get the test steps, executions, etc. unless the issue type is called "Test". This dead-simple optimization allows mixing non-test issues with test issues in the same export without performance penalty.

If your test issue type is named differently or you have multiple issue types for tests, you can change this filtering logic in the following method in zephyr-tool.groovy:

private static isTest(def issue) {
	issue.issueType.name == "Test"
}
"Executed On" does not include the time part (only the date)

The Zephyr API returns this field as date-only (ex: "29/Aug/17"), albeit this is a complete date-time in the Zephyr web UI (ex: "2017/08/29 10:56").

We consider this a design issue in the Zephyr API and reported this to Zephyr team here. (Please vote that topic to increase its importance for the Zephyr team.)

When exporting step results, "Step", "Test Data", "Expected Result" and "Comment" texts are joined to a single-line string

The Zephyr API returns these fields without line-breaks.

We consider this a design issue in the Zephyr API and reported this to Zephyr team here. (Please vote that topic to increase its importance for the Zephyr team.)

When exporting step results, step defects are not associated with the steps, but with the executions

The Zephyr API returns the defects (including both execution-level and step-level defects) in the format "BUG-1, BUG-2 | BUG-3, BUG-4". In this string the issue keys before the pipe character are execution-level defects, while the ones after the pipe are step-level ones. From this information, one can separate execution-level defects from step-level defects, but cannot know which step the step-level defects are associated with.

We consider this a design issue in the Zephyr API and reported this to Zephyr team here. (Please vote that topic to increase its importance for the Zephyr team.)

I am using some older Zephyr version and the export does not work

Our integration party relies on the /execution/export API end-point provided by the Zephyr API. The XML document format generated by this API end-point has been changed multiple times before it reached its current shape. Therefore, our integration works with 3.2.0.32002611 and newer Zephyr versions.

Please note that this is possible to re-configure the zephyr-tool.groovy script for older Zephyr versions if you are restricted to one of those. In that case, just contact us.

Learn more about Zephyr

See the Zephyr page (at its own vendor).