|
We're running 3.4.1 and we're still seeing this problem.
As of JIRA 3.7, Export to Excel exports all issues, not just a single page.
Lars is right. I just tried it on jira.atlassian.com by trying to export All JIRA issues. The Excel spredsheet only had 1000 issues, and I didn't see any tempmax parameter in the URL.
Could this be related to I verified that this issue still exists in JIRA 3.7.1.
Is there any workaround for 3.7 or 3.7.1?
If not, is there a scheduled release date for 3.7.3? The 1000 row limitation has become a hot issue in our deployment. Marty,
I think in JIRA 3.7 through to 3.7.2 all you need to do is add tempMax=1000000 (1 million) to the URL. Cheers, Removed Tims comment as it will cuase crawlers to retrieve 1000s of issues from JIRA. Here is a comment with corrected links:
This issue has been properly resolved for 3.7.3. The issue view links on the Issue Navigator (printable, full content, XML, Word, Excel etc.) will now return all of the issues displayed by the current filter (up to 1000). You can return more issues by modifying the tempMax URL parameter in the link, for example: http://<your-jira>/sr/jira.issueviews:searchrequest-excel-all-fields/temp/SearchRequest.xls?&pid=10000&sorter/field=issuekey&sorter/order=DESC&tempMax=1000 would become: &tempMax=5500" title="Visit page outside Jira">http://<your-jira>/sr/jira.issueviews:searchrequest-excel-all-fields/temp/SearchRequest.xls?&pid=10000&sorter/field=issuekey&sorter/order=DESC&tempMax=5500 if you wanted to return the first 5500 issues of your dataset. If you want to return ALL of your issues, remove the tempMax parameter altogether, for example: http://<your-jira>/sr/jira.issueviews:searchrequest-excel-all-fields/temp/SearchRequest.xls?&pid=10000&sorter/field=issuekey&sorter/order=DESC Come on, making users fiddle around with URLs can't be a proper resolution.
Why is there a limitation to 1000 at all? And why is it not communicated through the interface when the limitation is exceeded? We now have plenty of Excel files stored away for auditing purposes which are useless because of this "secret" limitation. Not good! The limitation to 1000 is needed mainly for public instances of JIRA, where automated crawlers do searches that find a lot of issues, and then export them. This needlessly consumes resources and affects other users. If the returned list is uncapped, crawlers can really consume a lot of resources.
So, if JIRA is running in Private mode ... you could get rid of it?
Is there a parameter somewhere in a property file, or is 1000 hardcoded? So far it has been hardcoded. I would prefer not to add too many 'switches', unless we have to.
In private mode, I guess the only thing I would be aware of is novice users can searching for all issues and then just clicking the Excel link to see what happens. Again consuming a lot of resources. In the future we are hoping to add an intermediate screen that would ask the user how many issues to export, whether they would like to export all issue fields or just configured columns, etc. I think that would look much better that simple links as we have now. For now, I guess the question is: how often would one actually need to export more than 1000 records to Excel? If this happens on regular basis, may I ask what the actual use case is? Cheers, An intermediate screen would be great. The main problem now is that the user thinks s/he exported all relevant issues, as there is no warning that the data was cut off after issue #1000.
Regarding the question how often (and why) excel exports are made: for example our QA folks export the issues for a version at certain milestones. This is done for auditing purposes and for doing fancy stuff within Excel (pivots, charts, etc.). And we do have some projects/products with huge amounts of issues. The intermediate screen would be helpful. As Atlassian folks might recall, doing full exports has been an on-going headache for me. We have some folks that export the entire db weekly in order to load it into access to do some rather complex reporting and graphing (nothing builtin to JIRA at this point comes close to what they're doing.)
I keep revisiting this issue with the intention of digging into the SQL to produce some sort of weekly dump for these folks, but since this is but one of many systems I have to maintain, it's not long before I get sidetracked onto something else I have to take care of. So later I have to come back and try to dig once again into the db layout and whatnot. I'm almost to the point where it would probably just be easier to give these individuals full access to the raw db and hope they do not look where they're not supposed to (a lot of projects on here), or that something horrible goes wrong. I just don't have time to be continually hassled by this one issue. Thank you for your feedback and sharing your use cases.
For the time being (i.e. before we get around to creating intermediary screen - JRA-12062) would it help if we make the default maximum number of exported issues configurable through jira-application.properties file (as suggested by Neal)? Note, if at the moment you cannot wait for us to do that, in JIRA 3.7.3 you can edit: Cheers, As part of the resolution to
We do not however consider this to be a final resolution of this issue, only an intermediate part of the full solution. cheers, Whoops, looks like this was actually committed as of 3.9, not 3.8.1.
Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Export to Excel doesn't export all records unless you are on Page 1
JRA-6572