How can I use the Export to Excel functionality for more than 1000 issues?

[Maria Giannatou]

We currently have a project that contains about 10k issues. I would like to know a way on how to export all of these issues to an excel file.

The currently implemented export to excel only exports the first 1000 of them without giving you a way to select (bulk select) the issues you would like to export in order to export, say, 10 different files containing 1k issues each.

This is what we want to do: Not bypass the 1k limitation (if this is possible, we could use it :), but a way to export different issues multiple times in order to export all the 10k of them.

[Nic Brough -Adaptavist-]

Look at the url the excel link generates, it'll have &tempmax=1000 in it. Copy the url and paste it, but add a zero or two to the end of the number.

If that does not work, then your admins have deliberately locked it down to prevent it, but most off-the-shelf installs will let you do it.

However, please bear in mind that the limit is there for a good reason - the Excel export especially thrashes the system and you can expect Jira to slow down for everyone while it's exporting 10k issues.

On a human level, you have to ask why you think you need 10k issues in an Excel sheet, as there's almost certainly a better way to achieve the end result...

[Maria Giannatou]

Exactly my point. What I would like to accomplish, is to have 10 separate excel files, each of them containing 1k issues. How could I do that, instead of having 10000 issues in one excel file?

[MattS]

Take a look at the URLs for each page and you can deduce what to do to download the data in parts.

[Andrew DeFaria]

This does not work for me. When I change the tempmax parameter and hit enter to have it re-execute the query I get a bunch of: ��W[s�6~ϯ~(�P����f:\Z���p�>�s,g�xmG�2��do6����am���Α��`|�ZՅy#���'W\�X~��t��MB"{ ��6��-�[��+T Rrh�%�h� on the browser page. If I try to use wget I get: Adefaria-lt:wget 'http://jira:8081/sr/jira.issueviews:searchrequest-excel-current-fields/temp/SearchRequest.xls?jqlQuery=%22Audience+Product+-+Chip%22+is+not+EMPTY+and+case+is+empty+ORDER+BY+cf%5B10124%5D+ASC&tempMax=2000'; --2014-12-08 15:40:04-- http://jira:8081/sr/jira.issueviews:searchrequest-excel-current-fields/temp/SearchRequest.xls?jqlQuery=%22Audience+Product+-+Chip%22+is+not+EMPTY+and+case+is+empty+ORDER+BY+cf%5B10124%5D+ASC&tempMax=2000 Resolving jira (jira)... 10.252.0.162 Connecting to jira (jira)|10.252.0.162|:8081... connected. HTTP request sent, awaiting response... 400 Bad Request 2014-12-08 15:40:04 ERROR 400: Bad Request. Adefaria-lt:

[Nic Brough -Adaptavist-]

What happens when you don't touch the tempmax parameter?

[Andrew DeFaria]

I get the first 1000 qualifying entries exported to an .xls file. Wait, now I'm getting all 1879 entries. I think this is because I configured the group jira-administrators to be unlimited.

[Andrew DeFaria]

As I said, I had made jira-administrators unlimited and that solved my problem.

[William Crighton [CCC]]

hmmm...are you talking about onDemand or the Server version? If it's the server version you can just modify the jpm.xml file increasing (one) of the following sets of values - NOTE the second set references each other so if you increase one you have to increase the other manually - and then restart your JIRA server. In the code blocks below the number at the start of every line is the line number in the file I was editing to pull this intel - the jpm.xml file - from JIRA version 6.3.1

363         <property>
    364             <key>jira.index.issue.maxqueuesize</key>
    365             <default-value>1000</default-value>
    366             <description>The maximum number of elements allowed on the queue before blocking on queue submission</description>
    367             <type>uint</type>
    368             <admin-editable>false</admin-editable>
    369             <sysadmin-editable>false</sysadmin-editable>
    370         </property>

1098         <property>
   1099             <!--
   1100                 The maximum number of results the Issue Navigator will request from a query
   1101                 - set this to zero or negative to be unrestricted (note that the server may forbid this, see below)
   1102             -->
   1103             <key>jira.search.views.default.max</key>
   1104             <default-value>1000</default-value>

1105             <type>uint</type>
   1106             <admin-editable>false</admin-editable>
   1107             <sysadmin-editable>false</sysadmin-editable>
   1108         </property>
   1109         <property>
   1110             <!--
   1111                 Whether search results are capped to a hard limit, otherwise return a 403 (Forbidden) to the client.
   1112                 Set this to negative (-1) or empty for unlimited results.
   1113                 NOTE: this must be EQUAL TO OR GREATER THAN jira.search.views.default.max above, otherwise all Issue Navigator links will fail with a 403
   1114             -->
   1115             <key>jira.search.views.max.limit</key>
   1116             <default-value>1000</default-value>
   1117             <type>uint</type>
   1118             <admin-editable>false</admin-editable>
   1119             <sysadmin-editable>false</sysadmin-editable>
   1120         </property>
   1121         <property>
   1122             <!--
   1123                 Regardless of the above, users in this group will be able to request search requests that are unlimited.
   1124                 This MUST be a valid group or empty.
   1125             -->
   1126             <key>jira.search.views.max.unlimited.group</key>
   1127             <default-value/>
   1128             <type>string</type>
   1129             <admin-editable>false</admin-editable>
   1130             <sysadmin-editable>false</sysadmin-editable>
   1131         </property>

The jpm.xml file is stored in the following location:

<jira base>/atlassian-jira/WEB-INF/classes/jpm.xml

-wc