The ability to export issues from Jira is one of the features that make Jira great, because it offers the freedom to work with external tools; though each case is unique, exported issues can be used for reports, audits, SLAs, and more. In this article we'll show you different ways to export issues from Jira.
Exporting issues is a great thing given that issue granularity is perfect for a spreadsheet, where each issue takes one row, and each metadata field takes one column.
Since the early days, Atlassian has promoted an open model where customers can tinker with source code, integrate seamlessly between applications, or check how suggestions for product improvements get traction (or not).
A symptom of Jira’s openness is the ability to export issues into a few standard formats that can then be read, reused, and repurposed.
It’s unsurprising that issue exports are a highly used feature. But since we keep meeting Jira fanboys and girls who ask us “why would you want to export issues from Jira,” we’ve gathered some of the most common use cases:
While it's true that you can export issues from Jira in three simple steps...
it's also true that the UI method has several limitations:
Starting with Jira 7.2.X, Atlassian decided to discontinue native exports to Excel, up until that point, whenever a user requested an excel export, Jira created an HTML file and saved it as an .xls file. When that operation was blocked, the export was preserved with the original HTML format.
Ok, so you are a heavy CSV user and have no problem moving back and forth between text files and large spreadsheets. The option to export issues to CSV should suit you perfectly!
At least in theory– Your satisfaction will depend on how much information you need to preserve.
You should know that native issue exports lack important data, including:
Just think for a moment of how many specs refer to screenshots, diagrams, and illustrations –if your goal is to migrate issues to another system, there will be a lot to be missed.
A thousand. That’s a totemic number for Atlassian, and many restrictions are set against it (for example, the bulk change maximum, query results, or even the indexing batches).
Issue exports fall within this limitation as well. Unless you use the workaround that I’ll explain in a minute.
Yes, we already covered it. But it’s still the most comfortable option, and if you’re happy with the result, you should probably stick to it. No reason to re-invent the wheel for nothing.
Check this extensive documentation on the different export formats. It’s interesting to play with the URL parameters for the XML view, which by the way can be embedded in a Confluence macro nicely.
If you don’t get what you want with the native exports, the easiest way to add functionality and get better, augmented exports of your issues is a third-party app, like Exporter for Jira.
You can also use general apps that can be applied to the task, like Jira CLI. But honestly speaking, that would defeat the purpose of simplicity, and you won’t be able to distribute export capabilities among end users.
Anything beyond this point is tech savvy, so don’t take it as a strict recommendation that you should do it: always weigh the pros and cons and the appropriateness for what you want to accomplish. If you’re not sure you understand the solution, don’t do it! It might work at once, or it might create larger problems you didn’t expect. In any case, all the items our list are real solutions –they can be done and because there are real, healthy people out there taking this route.
If you feel comfortable starting and restarting your instance, this option is as close as you will get to the good old excel export days. As of July 2018, it’s still working in the newest Jira 7 versions, including 7.10.
However, be aware that HTML exports might be deprecated anytime, so any processes that rely on this configuration may have to be reviewed when you least expect it.
Instructions:
jira.export.excel.enabled=trueAtlassian suggests doing larger exports in batches to avoid Out of Memory Exceptions. But if you’re properly monitoring the performance of your instance, if you feel comfortable testing how far it can go without crashing the application, or if you have too many issues to take the batches approach, you can play with the 1,000-limit or remove it altogether.
jira.search.views.default.max=[new max] Depending on who is exporting and for what purpose, you may want to remove the restriction for Jira administrators. For example, every IT manager at your company.
Remember that the issues of your export will be based on the results of your current filter in the issue navigator. Make sure that your super users understand the responsibility of the unlimited exports, and how they may affect performance.
Here are the instructions, same source as above. By this time, they should sound familiar:
jira.search.views.max.unlimited.group=jira-administrators The biggest drawback for Cloud instances of Jira is that customizations are not allowed. Some restricted functions may be configured by Atlassian Technical Support (ATS) by raising a Cloud project ticket at https://support.atlassian.com.
If you’re considering that course of action for expanding the maximum size of your issue exports, stop right there: this is the way to go.
This solution is not a great idea unless the reason for exporting your issues is… a backup process or a migration. Here are Atlassian’s full instructions.
Getting the backup file is simple. The tricky part is extracting only the issues in the entities.xml file, where they coexist with projects, users, groups, components… It will be a matter of chopping the XML down to the issues.
If anyone in your team is sufficiently familiar with scripting in Java, it’s am excellent option to submit the JQL query through the Java API. You’ll be talking to Jira in its source language.
Here is the query:String jql="assignee=currentUser()"; SearchService.ParseResult parseResult = searchService.parseQuery(applicationUser, jql); if (parseResult.isValid()) { try { /** * Execute the search and get the issues */ List issues = searchService.search(applicationUser, parseResult.getQuery(), PagerFilter.getUnlimitedFilter()).getIssues(); }catch (SearchException ex){ LOGGER.error("Error searching: ",ex); } } else { LOGGER.error("Error parsing: " + parseResult.getErrors()); }
Click here to see the full snippet, including authentication and imports. Just add a class and a method to call it.
Following the GET method of the REST API, once you’re logged into Jira you’ll be able to retrieve all the issues for a given JQL from a URL:
Method: GET
Url: JIRA_BASE_URL/JIRA_CONTEXT/rest/api/2/search?jql="assignee=currentUser()" One thing you want to avoid is going through the resulting JSON as a user. Here is just the start of what the data for an issue looks like:
… and it goes on for yet 86 lines.
Of course, the flipside is the flexibility of treating the data for whichever purpose you want it, including reporting.
No Comments Yet
Let us know what you think