Export all issues

[Saadiq Patel]

Is it possible to export all issues in the On-Demand version of JIRA? i see only 1000 issues can be exported and we have approx 6000...

Can be quite time consuming merging into one file for reporting.

According to the below it appears not possible,

https://confluence.atlassian.com/display/JIRAKB/Export+More+Than+1000+Results+to+Excel

also tried, increading tempmax value in URL, but still a no go.

Ideas?

[Saadiq Patel]

Yep already tried both methods same output

[Sai Kiran]

@Saadiq Patel  Is there any way to export all the issues that are in Backlog in an excel format ??

[Sai Kiran]

Is there any way to export all the issues in the backlog ? @Saadiq Patel

[Nic Brough -Adaptavist-]

This is a five year old question and not related to what you're asking.  I'd ask a new one.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

I regularly (Bamboo build) export issues from JIRA OnDemand to a local database for reporting in Confluence. In my case it is just a few thousand and I have scripted it for performance. I simple way of doing this that probably is sufficient for your purposes is just using csv: How to export JIRA issues to CSV

[Saadiq Patel]

Thanks Bob, using the command line tools from a window clients and connecting to a OnDemand instance, what other tools are required to run the export?

[Bob Swift OSS (Bob Swift Atlassian Apps)]

The JCLI tool depends on java being installed. That is all. Make sure remote API support is enabled on your OnDemand instance - go to Admin -> General Configuration

[Saadiq Patel]

Great, one query when i used the rest api there were proxy parameters that needed to be in my argurment, is there proxy support for JCLI?

[Bob Swift OSS (Bob Swift Atlassian Apps)]

Yes, I believe others have done that. I seem to remember having to specify the proxy parameters on the java command (in your jira.sh or atlassian.sh file start file). A quick reference to this post suggests something like:

-Dhttp.proxyHost=xxx -Dhttp.proxyPort=xxxx

[Saadiq Patel]

Thanks Bob,

I tested this from a local test instance we have and the tool would fit our purpose, however i don't think it will work with our OnDemand due to proxy issues and including all available parameters in the command line tool results in same issue below

Cause: ; nested exception is:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

[Bob Swift OSS (Bob Swift Atlassian Apps)]

Well, I think it can be set up to work through the proxy, I just don't know how to advice you :(. Hopefully someone else familar with proxy use with Java can chime in here.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

Try -Dhttps.proxyHost=xxxx. I forgot the s. Probably don't need to specify the port.

[Nic Brough -Adaptavist-]

No, you can't export them this way.

The only real way to do it is to create a backup and download it, then extract the data you need from the raw xml. Which is very complex.

However. As you've mentioned you are doing this for "reporting", you might find it more useful to look at what the reporting is doing. Most of the cases where someone has asked me for "a copy of everything", they've ended up with reports that are, at best, useless, and in most cases, downright wrong.

Could you tell us what reporting you are actually looking for? There's a good chance Jira can either tell you itself, or one of its reports can give you a much better start than "show me everything"

[Saadiq Patel]

Thanks Nic for the quick reponse.

Obviously we have x amount of issues, and we get user requests for this and that field etc...

I'm trying to populate a report, so we can actually see what fields are in use in the system, and what are not.

Originally during initial setup, there were a lot of fields added... some may not have been used, so we're trying to keep it streamline and see what we cna remove.

[Nic Brough -Adaptavist-]

Yes, that makes sense. However, it's a one-off housekeeping exercise - that does sort of lend itself to a quick grab of all data, but as that's quite difficult here, I'd try a different approach, one with a bit more human analysis

First, nip into the list of all your custom fields and take a copy of all their names. That simply gives you a list of fields you want to check.

Secondly, remove any from the list that you already know you want to keep. No point in looking at them, you know you want them.

Third, the boring bit. Go to "search for issues" and then the advanced search. For each field you want to check, use the JQL "<field> is not empty".

If you get a high number of results, the field is being used a lot. If you get no results, delete the field because no-one is using it. If you get a small number of results, then you'll need to investigate further, it might be junk, or genuine.